From issues at jboss.org Sat Nov 1 04:04:35 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Sat, 1 Nov 2014 04:04:35 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1896) JGroups 3.4.6 download dir has jgroups-3.4.5.Final.jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban resolved JGRP-1896. ---------------------------- Resolution: Done done > JGroups 3.4.6 download dir has jgroups-3.4.5.Final.jar > ------------------------------------------------------ > > Key: JGRP-1896 > URL: https://issues.jboss.org/browse/JGRP-1896 > Project: JGroups > Issue Type: Release > Affects Versions: 3.4.6 > Reporter: Justin Cranford > Assignee: Bela Ban > Priority: Minor > Fix For: 3.4.6 > > > The download directory for jgroups-3.4.6.Final.jar has wrong version - jgroups-3.4.5.Final.jar. > http://sourceforge.net/projects/javagroups/files/JGroups/3.4.6.Final/ > README 2014-09-11 602 Bytes 22 weekly downloads i > jgroups-sources.jar 2014-09-11 959.8 kB 11 weekly downloads i > jgroups-3.4.5.Final.jar 2014-09-11 2.2 MB 11 weekly downloads i > http://sourceforge.net/projects/javagroups/files/JGroups/3.4.5.Final/ > README 2014-08-11 602 Bytes 11 weekly downloads i > jgroups-sources.jar 2014-08-11 959.8 kB 11 weekly downloads i > jgroups-3.4.5.Final.jar 2014-08-11 2.2 MB 11 weekly downloads i -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Nov 1 05:02:35 2014 From: issues at jboss.org (=?UTF-8?Q?Marcial_Ati=C3=A9nzar_Navarro_=28JIRA=29?=) Date: Sat, 1 Nov 2014 05:02:35 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016557#comment-13016557 ] Marcial Ati?nzar Navarro commented on WFLY-4037: ------------------------------------------------ It's a cluster problem? I only have a single instance standalone, running with profile standalone-full.xml. > Error 500 accessing png,css, rest > --------------------------------- > > Key: WFLY-4037 > URL: https://issues.jboss.org/browse/WFLY-4037 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Marcial Ati?nzar Navarro > Assignee: Paul Ferraro > Priority: Critical > > I've this error: > {code} > 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on. > at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275) > at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231) > at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225) > at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.CacheImpl.get(CacheImpl.java:377) > at org.infinispan.CacheImpl.get(CacheImpl.java:369) > at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271) > at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54) > at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34) > at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38) > at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50) > at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77) > at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Nov 1 18:52:35 2014 From: issues at jboss.org (Karl Nicholas (JIRA)) Date: Sat, 1 Nov 2014 18:52:35 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: Karl Nicholas created WFLY-4044: ----------------------------------- Summary: Wildfly service will not start on fedora 20 - 64 bit Key: WFLY-4044 URL: https://issues.jboss.org/browse/WFLY-4044 Project: WildFly Issue Type: Feature Request Components: Server Affects Versions: 8.1.0.Final Environment: Fedora 20 - updates installed Reporter: Karl Nicholas Assignee: Jason Greene standalone.sh starts wildfly ok but systemctl start service fails: [root at localhost system]# yum install wildfly Loaded plugins: langpacks, refresh-packagekit Package wildfly-8.1.0-3.fc20.noarch already installed and latest version Nothing to do [root at localhost system]# systemctl start wildfly [root at localhost system]# systemctl status wildfly wildfly.service - The WildFly Application Server Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) Main PID: 7658 (code=exited, status=1/FAILURE) Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Nov 1 20:14:35 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Sat, 1 Nov 2014 20:14:35 -0400 (EDT) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-4044: --------------------------------- Assignee: Marek Goldmann (was: Jason Greene) > Wildfly service will not start on fedora 20 - 64 bit > ---------------------------------------------------- > > Key: WFLY-4044 > URL: https://issues.jboss.org/browse/WFLY-4044 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Environment: Fedora 20 - updates installed > Reporter: Karl Nicholas > Assignee: Marek Goldmann > > standalone.sh starts wildfly ok but systemctl start service fails: > [root at localhost system]# yum install wildfly > Loaded plugins: langpacks, refresh-packagekit > Package wildfly-8.1.0-3.fc20.noarch already installed and latest version > Nothing to do > [root at localhost system]# systemctl start wildfly > [root at localhost system]# systemctl status wildfly > wildfly.service - The WildFly Application Server > Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) > Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago > Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) > Main PID: 7658 (code=exited, status=1/FAILURE) > Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. > Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE > Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. > [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Nov 2 04:47:35 2014 From: issues at jboss.org (Gregor Tudan (JIRA)) Date: Sun, 2 Nov 2014 04:47:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-522) kie-maven-plugin "file encoding" should be configurable. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016574#comment-13016574 ] Gregor Tudan commented on DROOLS-522: ------------------------------------- If this bites you (i.e. when your rules contain non-ascii characters) a possible workaround is setting the environment variable JAVA_TOOL_OPTIONS: {code} JAVA_TOOL_OPTIONS="-Dfile.encoding=UTF-8" {code} > kie-maven-plugin "file encoding" should be configurable. > -------------------------------------------------------- > > Key: DROOLS-522 > URL: https://issues.jboss.org/browse/DROOLS-522 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.1.0.Beta4 > Reporter: Takami Hirata > Assignee: Mark Proctor > > When generating kjar using kie-maven-plugin, file encoding of DRLs and other plain text file should be configurable. > Default value of encoding should refer {code}${project.build.sourceEncoding}{code}. > Maven Guideline: http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Nov 2 10:05:36 2014 From: issues at jboss.org (Borisa Zivkovic (JIRA)) Date: Sun, 2 Nov 2014 10:05:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1893) ENCRYPT: Thread safety issues during key changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016578#comment-13016578 ] Borisa Zivkovic commented on JGRP-1893: --------------------------------------- I am getting same exception (Windows 8, Hotspot (build 1.7.0_51-b13), JGroups 3.5.1.Final Nov 02, 2014 3:01:59 PM org.jgroups.logging.JDKLogImpl error SEVERE: failed setting ip_ttl java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339) at org.jgroups.protocols.UDP.createSockets(UDP.java:368) at org.jgroups.protocols.UDP.start(UDP.java:270) at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966) at org.jgroups.JChannel.startStack(JChannel.java:889) at org.jgroups.JChannel._preConnect(JChannel.java:547) at org.jgroups.JChannel.connect(JChannel.java:282) at org.jgroups.JChannel.connect(JChannel.java:273) I am using udp.xml from jgroups-3.5.1.Fina.jar > ENCRYPT: Thread safety issues during key changes > ------------------------------------------------ > > Key: JGRP-1893 > URL: https://issues.jboss.org/browse/JGRP-1893 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > > For symmetric encryption, ENCRYPT has members with shared state: secret key, version and ciphers. In order for to provide consistent state between different threads accessing these members, they should be synchronized. > I have implemented one solution by wrapping the state in separate object which can be found here: > https://github.com/tepitebson/JGroups/tree/ENCRYPT_Thread_safety > I also have replaced the WeakHashMap holding the previous keys with Cache in google's guava library so my solution probably is not suitable for an official solution. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Nov 2 10:05:36 2014 From: issues at jboss.org (Borisa Zivkovic (JIRA)) Date: Sun, 2 Nov 2014 10:05:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1893) ENCRYPT: Thread safety issues during key changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016578#comment-13016578 ] Borisa Zivkovic edited comment on JGRP-1893 at 11/2/14 10:05 AM: ----------------------------------------------------------------- I am getting same exception (Windows 8, Hotspot (build 1.7.0_51-b13), JGroups 3.5.1.Final Nov 02, 2014 3:01:59 PM org.jgroups.logging.JDKLogImpl error SEVERE: failed setting ip_ttl java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339) at org.jgroups.protocols.UDP.createSockets(UDP.java:368) at org.jgroups.protocols.UDP.start(UDP.java:270) at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966) at org.jgroups.JChannel.startStack(JChannel.java:889) at org.jgroups.JChannel._preConnect(JChannel.java:547) at org.jgroups.JChannel.connect(JChannel.java:282) at org.jgroups.JChannel.connect(JChannel.java:273) I am using udp.xml from jgroups-3.5.1.Final.jar was (Author: borisha): I am getting same exception (Windows 8, Hotspot (build 1.7.0_51-b13), JGroups 3.5.1.Final Nov 02, 2014 3:01:59 PM org.jgroups.logging.JDKLogImpl error SEVERE: failed setting ip_ttl java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.jgroups.protocols.UDP.setTimeToLive(UDP.java:339) at org.jgroups.protocols.UDP.createSockets(UDP.java:368) at org.jgroups.protocols.UDP.start(UDP.java:270) at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966) at org.jgroups.JChannel.startStack(JChannel.java:889) at org.jgroups.JChannel._preConnect(JChannel.java:547) at org.jgroups.JChannel.connect(JChannel.java:282) at org.jgroups.JChannel.connect(JChannel.java:273) I am using udp.xml from jgroups-3.5.1.Fina.jar > ENCRYPT: Thread safety issues during key changes > ------------------------------------------------ > > Key: JGRP-1893 > URL: https://issues.jboss.org/browse/JGRP-1893 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > > For symmetric encryption, ENCRYPT has members with shared state: secret key, version and ciphers. In order for to provide consistent state between different threads accessing these members, they should be synchronized. > I have implemented one solution by wrapping the state in separate object which can be found here: > https://github.com/tepitebson/JGroups/tree/ENCRYPT_Thread_safety > I also have replaced the WeakHashMap holding the previous keys with Cache in google's guava library so my solution probably is not suitable for an official solution. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Nov 2 11:52:35 2014 From: issues at jboss.org (Karl Nicholas (JIRA)) Date: Sun, 2 Nov 2014 11:52:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016580#comment-13016580 ] Karl Nicholas commented on WFLY-4044: ------------------------------------- Just to add to the information: my fedora box is recently installed, and it installed OS updates and LibreOffice updates yesterday. I have a bit of python stuff on there, but nothing major. I have PyCharm (3.0.4?) installed. > Wildfly service will not start on fedora 20 - 64 bit > ---------------------------------------------------- > > Key: WFLY-4044 > URL: https://issues.jboss.org/browse/WFLY-4044 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Environment: Fedora 20 - updates installed > Reporter: Karl Nicholas > Assignee: Marek Goldmann > > standalone.sh starts wildfly ok but systemctl start service fails: > [root at localhost system]# yum install wildfly > Loaded plugins: langpacks, refresh-packagekit > Package wildfly-8.1.0-3.fc20.noarch already installed and latest version > Nothing to do > [root at localhost system]# systemctl start wildfly > [root at localhost system]# systemctl status wildfly > wildfly.service - The WildFly Application Server > Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) > Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago > Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) > Main PID: 7658 (code=exited, status=1/FAILURE) > Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. > Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE > Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. > [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Nov 2 18:18:35 2014 From: issues at jboss.org (Dennis Reed (JIRA)) Date: Sun, 2 Nov 2014 18:18:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1888) FD_SOCK race condition during stop In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Reed updated JGRP-1888: ------------------------------ Attachment: jgrp-1888-test.tar.gz Attached test case (instead of checking it in, because it uses Byteman which isn't that easy to integrate into 2.6.x tests) > FD_SOCK race condition during stop > ---------------------------------- > > Key: JGRP-1888 > URL: https://issues.jboss.org/browse/JGRP-1888 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.6.16 > Reporter: Dennis Reed > Assignee: Dennis Reed > Fix For: 2.6.23 > > Attachments: jgrp-1888-test.tar.gz > > > There is a race condition in FD_SOCK between stop() shutting down the pinger thread and the BroadcastTask. > It first shuts down the broadcast task, and then the pinger thread. > If the pinger thread generates a new suspected event in this interval, it re-starts the broadcast task, which creates a new thread suspecting that node repeatedly until the JVM exits. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Nov 2 18:46:35 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Sun, 2 Nov 2014 18:46:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016585#comment-13016585 ] Stuart Douglas commented on WFLY-4037: -------------------------------------- It looks like an issue with clustered SSO > Error 500 accessing png,css, rest > --------------------------------- > > Key: WFLY-4037 > URL: https://issues.jboss.org/browse/WFLY-4037 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Marcial Ati?nzar Navarro > Assignee: Paul Ferraro > Priority: Critical > > I've this error: > {code} > 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on. > at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275) > at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231) > at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225) > at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.CacheImpl.get(CacheImpl.java:377) > at org.infinispan.CacheImpl.get(CacheImpl.java:369) > at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271) > at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54) > at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34) > at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38) > at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50) > at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77) > at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Nov 2 18:53:35 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Sun, 2 Nov 2014 18:53:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3873) AJP-connector mangles SOAP-request In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016586#comment-13016586 ] Stuart Douglas commented on WFLY-3873: -------------------------------------- This should be fixed, do you have any way of reproducing it? > AJP-connector mangles SOAP-request > ---------------------------------- > > Key: WFLY-3873 > URL: https://issues.jboss.org/browse/WFLY-3873 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Linux > reverse-proxy from Apache 2.2 via mod_proxy_ajp to AJP connector on WildFly 8.1.0-Final > Reporter: Gerke Ephorus > Assignee: Stuart Douglas > Labels: .net, ajp, soap > > When connecting to WildFly 8.1.0-Final SOAP-service from a .NET application via a reverse-proxy (Apache 2.2 with mod_proxy_ajp to the AJP-connector) it looks like the payload SOAP package gets mangled: > {noformat} > 2014-09-19 08:45:05,206 WARNING [org.apache.cxf.phase.PhaseInterceptorChain] (default task-99) Interceptor for {http://ephorus.com/document-processor/ws/}DocumentProcessor has thrown exception, unwinding now: java.lang.RuntimeException: > Couldn't parse stream. > at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1447) > at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:123) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) > at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:241) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:93) > at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:133) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136) > at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi-2.2.2.Final.jar:2.2.2.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:101) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20] > Caused by: com.ctc.wstx.exc.WstxIOException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1) > at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:536) > at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:585) > at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:610) > at com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:316) > at __redirected.__XMLInputFactory.createXMLStreamReader(__XMLInputFactory.java:142) [jboss-modules.jar:1.3.3.Final] > at org.apache.cxf.staxutils.StaxUtils.createXMLStreamReader(StaxUtils.java:1445) > ... 40 more > Caused by: java.io.CharConversionException: Invalid UTF-8 start byte 0x95 (at char #4, byte #-1) > at com.ctc.wstx.io.UTF8Reader.reportInvalidInitial(UTF8Reader.java:303) > at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:189) > at com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:250) > at com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:133) > at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:531) > ... 45 more > {noformat} > Connecting to the same SOAP-service via the reverse-proxy via the AJP from a different party/client does not show this problem. > Connecting to the same SOAP-service directly to the http-connector on the same WildFly 8.1.0-Final server does not show this problem. > Wild guess is that it depends somehow on the HTTP-headers of the .NET client. These are the headers captured via Fiddler-http-proxy on the client-side: > {noformat} > POST http://some.host.com/doce/Foo/Bar HTTP/1.1 > User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3082) > Content-Type: text/xml; charset=utf-8 > SOAPAction: "http://host/some/soap-action/ws/addDocument" > Host: some.host.com > Content-Length: 6592 > Expect: 100-continue > Connection: Keep-Alive > Accept: application/json, text/plain, */* > {noformat} > There is a small change it's the same root-cause as [WFLY-2999]. Maybe I'll find the time to test this on 9.0.0-Beta1. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Nov 2 23:18:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sun, 2 Nov 2014 23:18:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3754) EJB StatefulSessionComponentInstance methodMap includes final Object methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016591#comment-13016591 ] RH Bugzilla Integration commented on WFLY-3754: ----------------------------------------------- James Livingston changed the Status of [bug 1132270|https://bugzilla.redhat.com/show_bug.cgi?id=1132270] from NEW to CLOSED > EJB StatefulSessionComponentInstance methodMap includes final Object methods > ---------------------------------------------------------------------------- > > Key: WFLY-3754 > URL: https://issues.jboss.org/browse/WFLY-3754 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 8.1.0.Final > Reporter: James Livingston > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > StatefulSessionComponentInstance has a methodMap which maintains the ChainedInterceptors for each method. That currently includes final Object methods which are not Business Methods for EJBs (EJB 3.1 4.9.5 "The method must not be declared as final or static"), which results in extra memory overhead for what I believe is the useless interceptors. > The amount of memory a ChainedInterceptor consumes varies between JVMs, but it is between 280 and 400 bytes in some heap dumps I looked at. With 6 final methods (wait, notify*, getClass) on java.lang.Object that adds approximately 2kb of memory use to each instance of each SFSB. > This can affect all BasicComponentInstance subclasses, but it is most noticeable for SFSBs due to the larger number of instances. > The list of methods comes from ComponentConfiguration.getDefinedComponentMethods(), but I'm not sure if filtering the final methods out should be done there or an EJB-specific class since the rule about final methods is from the EJB spec. I'm also not sure if toString, equals and hashCode() should be treated as EJB business methods either. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 00:08:35 2014 From: issues at jboss.org (James Livingston (JIRA)) Date: Mon, 3 Nov 2014 00:08:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-210) IO error during deployment scanning triggers undeployment In-Reply-To: References: Message-ID: James Livingston created WFCORE-210: --------------------------------------- Summary: IO error during deployment scanning triggers undeployment Key: WFCORE-210 URL: https://issues.jboss.org/browse/WFCORE-210 Project: WildFly Core Issue Type: Bug Components: Server Affects Versions: 1.0.0.Alpha10 Reporter: James Livingston Assignee: Jason Greene If an IO error such as reaching the file descriptor limit occurs during deployment scanning, the scanner continues with an empty deployment list causing it to undeploy applications. This occurs because FileSystemDeploymentService.scanDirectory() treats File.listFiles() returning null as an empty list rather than an error. http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 notes that it returns an empty array if the directory is empty, and null if it is not a directory or an IO error occurs. It should instead respond to a null return value by aborting the scanner run, with a log message, and not proceed to undeploy applications. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 00:08:36 2014 From: issues at jboss.org (Hariprasad Taduru (JIRA)) Date: Mon, 3 Nov 2014 00:08:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-638) KnowledgeAgent incremental build stuck infinite if have two rules with same condition in steam mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016592#comment-13016592 ] Hariprasad Taduru commented on DROOLS-638: ------------------------------------------ We are facing the above issue and not able to get a work around as well. Seems like a bug in the engine. Could you please clarify on this? > KnowledgeAgent incremental build stuck infinite if have two rules with same condition in steam mode > --------------------------------------------------------------------------------------------------- > > Key: DROOLS-638 > URL: https://issues.jboss.org/browse/DROOLS-638 > Project: Drools > Issue Type: Bug > Affects Versions: 5.6.0.Final > Environment: Windows 8 64bit Machine, Java jdk1.7.0_51 > Reporter: Vinay Pareek > Assignee: Mark Proctor > Attachments: AgentTest.zip > > > If we have two rules on same condition in Steam mode, first time agent able to pick both and work fine. > When we update any rule (then part), KnowledgeAgent will stuck infinite after printing below logs. > [2014-10-24 17:59:04,066:debug] KnowledgeAgent received ChangeSet changed notification > [2014-10-24 17:59:04,066:info] KnowledgeAgent applying ChangeSet > [2014-10-24 17:59:04,067:debug] KnowledgeAgent removing mappings for resource=[FileResource file='rule\streamRule.drl'] with unsubscribe=false > [2014-10-24 17:59:04,067:debug] KnowledgeAgent rebuilding KnowledgeBase using ChangeSet > [2014-10-24 17:59:04,076:info] KnowledgeAgent performing an incremental build of the ChangeSet > [2014-10-24 17:59:04,193:debug] KnowledgeAgent: Diffing: [FileResource file='rule\streamRule.drl'] > Below is code snippet for KnowledgeAgent > KnowledgeAgentConfiguration kaconf = KnowledgeAgentFactory > .newKnowledgeAgentConfiguration(); > kaconf.setProperty("drools.agent.scanDirectories", "true"); > kaconf.setProperty("drools.agent.newInstance", "false"); > KnowledgeBaseConfiguration config = KnowledgeBaseFactory > .newKnowledgeBaseConfiguration(); > config.setOption(EventProcessingOption.STREAM); > KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config); > final KnowledgeAgent kagent = KnowledgeAgentFactory.newKnowledgeAgent( > "kagent", kbase, kaconf); > kagent.setSystemEventListener(new PrintStreamSystemEventListener()); > kagent.addEventListener(new KnowledgeAgentEventListener() { > public void resourceCompilationFailed( > ResourceCompilationFailedEvent arg0) { > LOGGER.error("Unable to compile Knowledge" + arg0.toString()); > throw new RuntimeException("Unable to compile Knowledge" > + arg0.toString()); > } > public void knowledgeBaseUpdated(KnowledgeBaseUpdatedEvent arg0) { > LOGGER.info("********** KBase was updated***********"); > } > public void beforeResourceProcessed( > BeforeResourceProcessedEvent arg0) { > } > public void beforeChangeSetProcessed( > BeforeChangeSetProcessedEvent arg0) { > } > public void beforeChangeSetApplied(BeforeChangeSetAppliedEvent arg0) { > } > public void afterResourceProcessed(AfterResourceProcessedEvent arg0) { > } > public void afterChangeSetProcessed( > AfterChangeSetProcessedEvent arg0) { > } > public void afterChangeSetApplied(AfterChangeSetAppliedEvent arg0) { > } > }); > ResourceChangeScannerConfiguration sconf = ResourceFactory > .getResourceChangeScannerService() > .newResourceChangeScannerConfiguration(); > sconf.setProperty("drools.resource.scanner.interval", "2"); > ResourceFactory.getResourceChangeScannerService().configure(sconf); > kagent.applyChangeSet(ResourceFactory > .newClassPathResource("changeset/changeSet.xml")); > ResourceFactory.getResourceChangeNotifierService().start(); > ResourceFactory.getResourceChangeScannerService().start(); -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 00:13:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 00:13:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-210) IO error during deployment scanning triggers undeployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-210: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1159709 > IO error during deployment scanning triggers undeployment > --------------------------------------------------------- > > Key: WFCORE-210 > URL: https://issues.jboss.org/browse/WFCORE-210 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha10 > Reporter: James Livingston > Assignee: Jason Greene > > If an IO error such as reaching the file descriptor limit occurs during deployment scanning, the scanner continues with an empty deployment list causing it to undeploy applications. > This occurs because FileSystemDeploymentService.scanDirectory() treats File.listFiles() returning null as an empty list rather than an error. http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 notes that it returns an empty array if the directory is empty, and null if it is not a directory or an IO error occurs. > It should instead respond to a null return value by aborting the scanner run, with a log message, and not proceed to undeploy applications. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 01:04:35 2014 From: issues at jboss.org (James Livingston (JIRA)) Date: Mon, 3 Nov 2014 01:04:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-201) UnboundedQueueThreadPool's keep-alive param is currently useless In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016593#comment-13016593 ] James Livingston commented on WFCORE-201: ----------------------------------------- Any preference for adding a core-threads parameter (so schema change etc), or just setting the executor's core-threads to 0? > UnboundedQueueThreadPool's keep-alive param is currently useless > ---------------------------------------------------------------- > > Key: WFCORE-201 > URL: https://issues.jboss.org/browse/WFCORE-201 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 1.0.0.Alpha10 > Reporter: James Livingston > > UnboundedQueueThreadPoolService currently sets the number of core thread and the maximum threads to the same value. As core threads are never removed, the keep-alive time parameter is useless. > Either the core threads should be lowered (to 0?) to allow timeouts, or the keep-alive parameter removed/deprecated. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 02:20:37 2014 From: issues at jboss.org (=?UTF-8?Q?Marcial_Ati=C3=A9nzar_Navarro_=28JIRA=29?=) Date: Mon, 3 Nov 2014 02:20:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016598#comment-13016598 ] Marcial Ati?nzar Navarro commented on WFLY-4037: ------------------------------------------------ If I activate sso betweens apps,it's cluster activated by default? > Error 500 accessing png,css, rest > --------------------------------- > > Key: WFLY-4037 > URL: https://issues.jboss.org/browse/WFLY-4037 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Marcial Ati?nzar Navarro > Assignee: Paul Ferraro > Priority: Critical > > I've this error: > {code} > 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on. > at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275) > at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231) > at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225) > at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.CacheImpl.get(CacheImpl.java:377) > at org.infinispan.CacheImpl.get(CacheImpl.java:369) > at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271) > at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54) > at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34) > at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38) > at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50) > at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77) > at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 02:39:36 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Mon, 3 Nov 2014 02:39:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1893) ENCRYPT: Thread safety issues during key changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016603#comment-13016603 ] Bela Ban commented on JGRP-1893: -------------------------------- Apparently, the JDK on Windows doesn't implement {{DatagramSocketImpl.setTimeToLive()}}. Can you try a different JDK (e.g. JDK 8), to see if it implements this method ? If not, Windows users will have to live with this until JGroups 4.0 (which switches to NIO.2). You can make the error message go away though by removing {{ip_ttl}} from the config. > ENCRYPT: Thread safety issues during key changes > ------------------------------------------------ > > Key: JGRP-1893 > URL: https://issues.jboss.org/browse/JGRP-1893 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > > For symmetric encryption, ENCRYPT has members with shared state: secret key, version and ciphers. In order for to provide consistent state between different threads accessing these members, they should be synchronized. > I have implemented one solution by wrapping the state in separate object which can be found here: > https://github.com/tepitebson/JGroups/tree/ENCRYPT_Thread_safety > I also have replaced the WeakHashMap holding the previous keys with Cache in google's guava library so my solution probably is not suitable for an official solution. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 02:55:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 02:55:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3978) PicketLink Subsystem EAP 6.4 Issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016606#comment-13016606 ] RH Bugzilla Integration commented on WFLY-3978: ----------------------------------------------- Ondrej Lukas changed the Status of [bug 1151002|https://bugzilla.redhat.com/show_bug.cgi?id=1151002] from ON_QA to VERIFIED > PicketLink Subsystem EAP 6.4 Issues > ----------------------------------- > > Key: WFLY-3978 > URL: https://issues.jboss.org/browse/WFLY-3978 > Project: WildFly > Issue Type: Task > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 03:01:35 2014 From: issues at jboss.org (Tero Leppikangas (JIRA)) Date: Mon, 3 Nov 2014 03:01:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1893) ENCRYPT: Thread safety issues during key changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016612#comment-13016612 ] Tero Leppikangas commented on JGRP-1893: ---------------------------------------- I believe that the implementation has been the same from Java 6 (http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b27/java/net/DualStackPlainDatagramSocketImpl.java#DualStackPlainDatagramSocketImpl.setTimeToLive%28int%29) and the implementation is the same in Java 8 (also with Sun's own JDK) The problem is that for multicast use, the ip_ttl is vital part of the configuration, thus cannot be removed from the config. Although the issue causes no problems, it is not nice to have such an exception printed out on every init of a stack. If the discussion about the TTL issue continues, I suppose the proper place for the conversation is under JGRP-1880. > ENCRYPT: Thread safety issues during key changes > ------------------------------------------------ > > Key: JGRP-1893 > URL: https://issues.jboss.org/browse/JGRP-1893 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > > For symmetric encryption, ENCRYPT has members with shared state: secret key, version and ciphers. In order for to provide consistent state between different threads accessing these members, they should be synchronized. > I have implemented one solution by wrapping the state in separate object which can be found here: > https://github.com/tepitebson/JGroups/tree/ENCRYPT_Thread_safety > I also have replaced the WeakHashMap holding the previous keys with Cache in google's guava library so my solution probably is not suitable for an official solution. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 05:09:35 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Mon, 3 Nov 2014 05:09:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4045) Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue In-Reply-To: References: Message-ID: Josef Cacek created WFLY-4045: --------------------------------- Summary: Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue Key: WFLY-4045 URL: https://issues.jboss.org/browse/WFLY-4045 Project: WildFly Issue Type: Enhancement Components: Test Suite Reporter: Josef Cacek Assignee: Josef Cacek Add a regression test for https://issues.jboss.org/browse/WFCORE-190 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 05:18:36 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Mon, 3 Nov 2014 05:18:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-211) HC is over eager to remove its content In-Reply-To: References: Message-ID: Emmanuel Hugonnet created WFCORE-211: ---------------------------------------- Summary: HC is over eager to remove its content Key: WFCORE-211 URL: https://issues.jboss.org/browse/WFCORE-211 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha10 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet Priority: Minor If you deploy the same war twice (same hash with different names) on a domain then undeploy one the content is removed from the HC while it is still referenced and potentially useable. The content is not removed from the servers content directory. To reproduce : deploy /home/ehsavoie/dev/wildfly/quickstart/ejb-in-war/target/wildfly-ejb-in-war.war --runtime-name=first.war --server-groups=main-server-group --name=first.war deploy /home/ehsavoie/dev/wildfly/quickstart/ejb-in-war/target/wildfly-ejb-in-war.war --runtime-name=second.war --server-groups=main-server-group --name=second.war undeploy first.war --all-relevant-server-groups -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 05:56:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 05:56:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016657#comment-13016657 ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Enrique Gonzalez Martinez changed the Status of [bug 1139202|https://bugzilla.redhat.com/show_bug.cgi?id=1139202] from ASSIGNED to MODIFIED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:32:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 06:32:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-112: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1149618, https://bugzilla.redhat.com/show_bug.cgi?id=1149623, https://bugzilla.redhat.com/show_bug.cgi?id=1149621 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1149618, https://bugzilla.redhat.com/show_bug.cgi?id=1149623) > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:42:35 2014 From: issues at jboss.org (Tero Leppikangas (JIRA)) Date: Mon, 3 Nov 2014 06:42:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change In-Reply-To: References: Message-ID: Tero Leppikangas created JGRP-1897: -------------------------------------- Summary: ENCRYPT might drop messages during key change Key: JGRP-1897 URL: https://issues.jboss.org/browse/JGRP-1897 Project: JGroups Issue Type: Bug Reporter: Tero Leppikangas Assignee: Bela Ban ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. This problem was noticed while doing some stress testing on the fix for JGRP-1893. When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. We thought of possible solutions to be. 1. Sender specific queue holding the messages received. 2. Starting to queue up messages until new view has been received I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:47:35 2014 From: issues at jboss.org (Tero Leppikangas (JIRA)) Date: Mon, 3 Nov 2014 06:47:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016674#comment-13016674 ] Tero Leppikangas commented on JGRP-1897: ---------------------------------------- Oh, my initial solution is here: https://github.com/tepitebson/JGroups/tree/ENCRYPT_queue_on_new_cipher > ENCRYPT might drop messages during key change > --------------------------------------------- > > Key: JGRP-1897 > URL: https://issues.jboss.org/browse/JGRP-1897 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > > ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. > This problem was noticed while doing some stress testing on the fix for JGRP-1893. > When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. > We thought of possible solutions to be. > 1. Sender specific queue holding the messages received. > 2. Starting to queue up messages until new view has been received > I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. > I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:48:36 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 06:48:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2275) StackOverflowError on DataSource resource injection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler resolved WFLY-2275. ---------------------------------- Resolution: Out of Date Out of Date > StackOverflowError on DataSource resource injection > --------------------------------------------------- > > Key: WFLY-2275 > URL: https://issues.jboss.org/browse/WFLY-2275 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.0.0.Beta1 > Reporter: Thomas Diesler > Assignee: Thomas Diesler > Attachments: standalone-osgi.xml > > > {code} > @Resource(name="java:comp/DefaultDataSource") > public DataSource ds; > {code} > leads to > {code} > 10:59:21,901 INFO [org.jboss.osgi.framework] (MSC service thread 1-3) JBOSGI011001: Bundle installed: resource-injection.jar:0.0.0 > 10:59:21,937 INFO [org.jboss.as.arquillian] (MSC service thread 1-3) Arquillian deployment detected: ArquillianConfig[service=jboss.arquillian.config."resource-injection.jar",unit=resource-injection.jar,tests=[org.jboss.test.osgi.example.resource.ResourceInjectionTestCase]] > 10:59:21,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."resource-injection.jar".Activate: org.jboss.msc.service.StartException in service jboss.deployment.unit."resource-injection.jar".Activate: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > Caused by: java.lang.StackOverflowError > at java.util.Vector.(Vector.java:127) [rt.jar:1.7.0_25] > at java.util.Vector.(Vector.java:144) [rt.jar:1.7.0_25] > at java.util.Vector.(Vector.java:153) [rt.jar:1.7.0_25] > at javax.naming.NameImpl.(NameImpl.java:273) [rt.jar:1.7.0_25] > at javax.naming.NameImpl.(NameImpl.java:277) [rt.jar:1.7.0_25] > at javax.naming.CompositeName.(CompositeName.java:231) [rt.jar:1.7.0_25] > at org.jboss.as.naming.util.NameParser.parse(NameParser.java:49) > at org.jboss.as.naming.NamingContext.parseName(NamingContext.java:496) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) > at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:302) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:140) > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:48:37 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 06:48:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1140) Support provisioning from a deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler resolved WFLY-1140. ---------------------------------- Resolution: Out of Date Out of Date > Support provisioning from a deployment > -------------------------------------- > > Key: WFLY-1140 > URL: https://issues.jboss.org/browse/WFLY-1140 > Project: WildFly > Issue Type: Feature Request > Components: Server > Reporter: Thomas Diesler > Assignee: Jason Greene > > This is currently not possible because it creates a nested management op, which deadlocks. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:48:37 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 06:48:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-893) Undeploy failure after deployment failure for ARQ tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler resolved WFLY-893. --------------------------------- Resolution: Out of Date Out of Date > Undeploy failure after deployment failure for ARQ tests > ------------------------------------------------------- > > Key: WFLY-893 > URL: https://issues.jboss.org/browse/WFLY-893 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Thomas Diesler > Assignee: Andrew Rubinger > > {code} > 04:22:14,469 INFO [org.jboss.as.server.deployment] (pool-2-thread-1) Content added at location /home/ondra/work/AS-7/ozizka-as7/testsuite/integration/target/jbossas/standalone/data/content/bf/815f1962565545e298089d58c3988d770833cb/content > 04:22:14,470 INFO [org.jboss.as.server.deployment] (MSC service thread 1-10) Starting deployment of "resteasy-osgi-client.war" > 04:22:14,677 INFO [org.jboss.as.server.controller] (pool-2-thread-1) Deployment of "resteasy-osgi-client.war" was rolled back with failure message {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"resteasy-osgi-client.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.osgi.cmpn\".\"4.2.0.200908310645\" ]"]} > 04:22:14,678 INFO [org.jboss.as.server.deployment] (MSC service thread 1-10) Stopped deployment resteasy-osgi-client.war in 1ms > 04:22:14,685 ERROR [org.jboss.as.controller] (pool-2-thread-1) Operation ("undeploy") failed - address: ([("deployment" => "resteasy-osgi-client.war")]): java.util.NoSuchElementException: No child 'runtime-name' exists > at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:362) [jboss-dmr-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.dmr.ModelNode.require(ModelNode.java:703) [jboss-dmr-1.0.0.Final.jar:1.0.0.Final] > at org.jboss.as.server.deployment.DeploymentUndeployHandler.execute(DeploymentUndeployHandler.java:58) > {code} > The test correctly fails with a deploy error including the cause > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.as.test.integration.osgi.jaxrs.RestEasyIntegrationTestCase > ------------------------------------------------------------------------------- > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 8.036 sec <<< FAILURE! > org.jboss.as.test.integration.osgi.jaxrs.RestEasyIntegrationTestCase Time elapsed: 0 sec <<< ERROR! > org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container > at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:58) > at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:111) > ... > Caused by: java.lang.Exception: {"Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"resteasy-osgi-client.war\".CONFIGURE_MODULE missing [ jboss.module.information.service.\"deployment.osgi.cmpn\".\"4.2.0.200908310645\" ]"]} > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:99) > at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:88) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:48:38 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 06:48:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1041) Add support for deployment triggered by another management operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler resolved WFLY-1041. ---------------------------------- Resolution: Out of Date Out of Date > Add support for deployment triggered by another management operation > -------------------------------------------------------------------- > > Key: WFLY-1041 > URL: https://issues.jboss.org/browse/WFLY-1041 > Project: WildFly > Issue Type: Feature Request > Components: Server > Reporter: Thomas Diesler > Assignee: Jason Greene > > This is related to [Provisioner service and Feature deployment|https://community.jboss.org/wiki/ProvisionerServiceAndFeatureDeployment] > If I remember correctly we cannot have nested management operations. A deployment being a management op can therefore not trigger another deployment op, right? > The general use case is that during deployment of A I want to deploy B which is required by A. Even more general - a user invoked mgmnt op should be able to trigger a deployment op. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:48:38 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 06:48:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1195) Provide embedded EJB3 test coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler resolved WFLY-1195. ---------------------------------- Resolution: Out of Date Out of Date > Provide embedded EJB3 test coverage > ----------------------------------- > > Key: WFLY-1195 > URL: https://issues.jboss.org/browse/WFLY-1195 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Thomas Diesler > > The TCK runs into issues with embedded EJB that are not caught by the AS7 test suite. Basic smoke testing should be provided. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:48:38 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 06:48:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does not work on MacOS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler resolved WFLY-1928. ---------------------------------- Resolution: Out of Date Fix Version/s: (was: Awaiting Volunteers) Out of Date > jboss-as-standalone.sh does not work on MacOS > --------------------------------------------- > > Key: WFLY-1928 > URL: https://issues.jboss.org/browse/WFLY-1928 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.0.0.Alpha4 > Reporter: Thomas Diesler > > {code} > FuseFabric:karaf at root> process-start root 3 > bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory > Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1 > bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:48:39 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 06:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1702) Investigate module wiring consistency at build time In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler resolved WFLY-1702. ---------------------------------- Resolution: Out of Date Fix Version/s: (was: 9.0.0.Beta1) Out of Date > Investigate module wiring consistency at build time > --------------------------------------------------- > > Key: WFLY-1702 > URL: https://issues.jboss.org/browse/WFLY-1702 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Thomas Diesler > > Due to the use of human wiring decisions it is possible that the initial modules wiring setup is incomplete/inconsistent. Various inconsistencies can occur > * There are code paths in a module that require a class load for which there is no dependency defined > * Modules define (stale) dependencies that are never used > * Modules define dependencies that are inconsistent in the class space -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:48:39 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 06:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-378) Provide ability to detect server shutdown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler resolved WFLY-378. --------------------------------- Resolution: Out of Date Fix Version/s: (was: 9.0.0.Beta1) Out of Date > Provide ability to detect server shutdown > ----------------------------------------- > > Key: WFLY-378 > URL: https://issues.jboss.org/browse/WFLY-378 > Project: WildFly > Issue Type: Feature Request > Components: Server > Reporter: Thomas Diesler > Assignee: Jason Greene > > The general use case is that a subsystem maintains state (on behalf of a deployment) that should be removed on explicit user interaction (i.e. mgmt op) but not on subsystem/server shutdown. This should also work in the domain case. Perhaps the ApplicationServerService (or similar) could be queried about whether it is currently shutting down. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:52:35 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 06:52:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4046) Container lifecycle event method invoked outside of extension observer method invocation In-Reply-To: References: Message-ID: Thomas Diesler created WFLY-4046: ------------------------------------ Summary: Container lifecycle event method invoked outside of extension observer method invocation Key: WFLY-4046 URL: https://issues.jboss.org/browse/WFLY-4046 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 9.0.0.Alpha1 Reporter: Thomas Diesler Assignee: Stuart Douglas Fix For: 9.0.0.Beta1 Cannot deploy war that uses camel-cdi This works in 8.1.0.Final {code} org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:53:35 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 3 Nov 2014 06:53:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4046) Container lifecycle event method invoked outside of extension observer method invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-4046: --------------------------------- Assignee: Jozef Hartinger (was: Stuart Douglas) > Container lifecycle event method invoked outside of extension observer method invocation > ---------------------------------------------------------------------------------------- > > Key: WFLY-4046 > URL: https://issues.jboss.org/browse/WFLY-4046 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Thomas Diesler > Assignee: Jozef Hartinger > Fix For: 9.0.0.Beta1 > > > Cannot deploy war that uses camel-cdi > This works in 8.1.0.Final > {code} > org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. > at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) > at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) > at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) > at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) > at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 06:54:35 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 06:54:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4046) Container lifecycle event method invoked outside of extension observer method invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016684#comment-13016684 ] Thomas Diesler commented on WFLY-4046: -------------------------------------- To reproduce, build: https://github.com/tdiesler/wildfly-camel/tree/2.0 > Container lifecycle event method invoked outside of extension observer method invocation > ---------------------------------------------------------------------------------------- > > Key: WFLY-4046 > URL: https://issues.jboss.org/browse/WFLY-4046 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Thomas Diesler > Assignee: Jozef Hartinger > Fix For: 9.0.0.Beta1 > > > Cannot deploy war that uses camel-cdi > This works in 8.1.0.Final > {code} > org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. > at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) > at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) > at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) > at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) > at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 07:15:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 07:15:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4045) Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4045: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1159814 > Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue > ------------------------------------------------------------------ > > Key: WFLY-4045 > URL: https://issues.jboss.org/browse/WFLY-4045 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > Add a regression test for https://issues.jboss.org/browse/WFCORE-190 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 07:25:35 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Mon, 3 Nov 2014 07:25:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016703#comment-13016703 ] Bela Ban commented on JGRP-1897: -------------------------------- Why is this an issue ? It doesn't happen often and if it does happen, since unicast messages are retransmitted (e.g. in {{UNICAST3}}), we'll end up receiving a dropped unicast a few hundred milliseconds later, anyway. > ENCRYPT might drop messages during key change > --------------------------------------------- > > Key: JGRP-1897 > URL: https://issues.jboss.org/browse/JGRP-1897 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > > ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. > This problem was noticed while doing some stress testing on the fix for JGRP-1893. > When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. > We thought of possible solutions to be. > 1. Sender specific queue holding the messages received. > 2. Starting to queue up messages until new view has been received > I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. > I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 07:33:36 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Mon, 3 Nov 2014 07:33:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4046) Container lifecycle event method invoked outside of extension observer method invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger resolved WFLY-4046. ----------------------------------- Fix Version/s: (was: 9.0.0.Beta1) Resolution: Rejected This is per specification. See http://docs.jboss.org/cdi/api/1.2/javax/enterprise/inject/spi/ProcessAnnotatedType.html#getAnnotatedType() CamelExtension can get around this by storing AnnotatedTypes, not ProcessAnnotatedType events here: https://github.com/tdiesler/camel/blob/trunk/components/camel-cdi/src/main/java/org/apache/camel/cdi/internal/CamelContextConfig.java#L39 > Container lifecycle event method invoked outside of extension observer method invocation > ---------------------------------------------------------------------------------------- > > Key: WFLY-4046 > URL: https://issues.jboss.org/browse/WFLY-4046 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Thomas Diesler > Assignee: Jozef Hartinger > > Cannot deploy war that uses camel-cdi > This works in 8.1.0.Final > {code} > org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. > at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) > at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) > at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) > at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) > at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 07:54:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 07:54:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3900) Unable to inject EJB Context into CDI Interceptor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016716#comment-13016716 ] RH Bugzilla Integration commented on WFLY-3900: ----------------------------------------------- Kabir Khan changed the Status of [bug 1149644|https://bugzilla.redhat.com/show_bug.cgi?id=1149644] from POST to MODIFIED > Unable to inject EJB Context into CDI Interceptor > ------------------------------------------------- > > Key: WFLY-3900 > URL: https://issues.jboss.org/browse/WFLY-3900 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > Attachments: inject-ejb-context-into-cdi-interceptor.jar, server.log > > > CDI Interceptor cannot inject EJB session context. > If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject. > See attached reproducer with source and log file. > private @Resource SessionContext sessionContext; > Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185) > ... 127 more -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:06:36 2014 From: issues at jboss.org (Wojciech Oczkowski (JIRA)) Date: Mon, 3 Nov 2014 08:06:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4047) SLSB with WebService Annotation generates duplicate endpoint when JMS transport used In-Reply-To: References: Message-ID: Wojciech Oczkowski created WFLY-4047: ---------------------------------------- Summary: SLSB with WebService Annotation generates duplicate endpoint when JMS transport used Key: WFLY-4047 URL: https://issues.jboss.org/browse/WFLY-4047 Project: WildFly Issue Type: Bug Reporter: Wojciech Oczkowski Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:07:36 2014 From: issues at jboss.org (Wojciech Oczkowski (JIRA)) Date: Mon, 3 Nov 2014 08:07:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4047) SLSB with WebService Annotation generates duplicate endpoint when JMS transport used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wojciech Oczkowski updated WFLY-4047: ------------------------------------- Affects Version/s: 8.1.0.Final > SLSB with WebService Annotation generates duplicate endpoint when JMS transport used > ------------------------------------------------------------------------------------ > > Key: WFLY-4047 > URL: https://issues.jboss.org/browse/WFLY-4047 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Wojciech Oczkowski > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:07:37 2014 From: issues at jboss.org (Wojciech Oczkowski (JIRA)) Date: Mon, 3 Nov 2014 08:07:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4047) SLSB with WebService Annotation generates duplicate endpoint when JMS transport used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wojciech Oczkowski updated WFLY-4047: ------------------------------------- Component/s: Web Services > SLSB with WebService Annotation generates duplicate endpoint when JMS transport used > ------------------------------------------------------------------------------------ > > Key: WFLY-4047 > URL: https://issues.jboss.org/browse/WFLY-4047 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final > Reporter: Wojciech Oczkowski > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:07:38 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 08:07:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3429) Classloader leak in JBossCachedAuthenticationManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016724#comment-13016724 ] RH Bugzilla Integration commented on WFLY-3429: ----------------------------------------------- Josef Cacek changed the Status of [bug 1103735|https://bugzilla.redhat.com/show_bug.cgi?id=1103735] from ON_QA to VERIFIED > Classloader leak in JBossCachedAuthenticationManager > ---------------------------------------------------- > > Key: WFLY-3429 > URL: https://issues.jboss.org/browse/WFLY-3429 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.1.0.Final > Reporter: Josef Cacek > Assignee: Emmanuel Hugonnet > Priority: Critical > > When using a security domain with {{cache-type="default"}}, then the ModuleClassLoader instances related to deployments leak through JBossCachedAuthenticationManager. > The problematic piece of code is the domainCache member variable which in the DomainInfo value holds a LoginContext instance. This LoginContext has member contextClassLoader which causes the leak. (It points to the ModuleClassLoader of the deployment). > One option to solve this issue could be to remove the cache entries which are related to the undeployed application. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:08:35 2014 From: issues at jboss.org (Tero Leppikangas (JIRA)) Date: Mon, 3 Nov 2014 08:08:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016725#comment-13016725 ] Tero Leppikangas commented on JGRP-1897: ---------------------------------------- Hmm, we run ENCRYPT on top of GMS and UNICAST3 underneath GMS, so it won't help us in the case where ENCRYPT itself drops the message. > ENCRYPT might drop messages during key change > --------------------------------------------- > > Key: JGRP-1897 > URL: https://issues.jboss.org/browse/JGRP-1897 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > > ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. > This problem was noticed while doing some stress testing on the fix for JGRP-1893. > When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. > We thought of possible solutions to be. > 1. Sender specific queue holding the messages received. > 2. Starting to queue up messages until new view has been received > I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. > I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:10:36 2014 From: issues at jboss.org (Wojciech Oczkowski (JIRA)) Date: Mon, 3 Nov 2014 08:10:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4047) SLSB with WebService Annotation generates duplicate endpoint when JMS transport used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wojciech Oczkowski updated WFLY-4047: ------------------------------------- Description: When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception: 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72] Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67) at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] ... 5 more Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115) at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119) at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49) at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95) at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895) at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) ... 13 more > SLSB with WebService Annotation generates duplicate endpoint when JMS transport used > ------------------------------------------------------------------------------------ > > Key: WFLY-4047 > URL: https://issues.jboss.org/browse/WFLY-4047 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final > Reporter: Wojciech Oczkowski > Assignee: Jason Greene > > When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception: > 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72] > Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) > at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) > at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129) > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67) > at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? > at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115) > at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119) > at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49) > at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95) > at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895) > at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) > ... 13 more -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:11:35 2014 From: issues at jboss.org (Wojciech Oczkowski (JIRA)) Date: Mon, 3 Nov 2014 08:11:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4047) SLSB with WebService Annotation generates duplicate endpoint when JMS transport used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wojciech Oczkowski updated WFLY-4047: ------------------------------------- Attachment: TestWSJMS.zip > SLSB with WebService Annotation generates duplicate endpoint when JMS transport used > ------------------------------------------------------------------------------------ > > Key: WFLY-4047 > URL: https://issues.jboss.org/browse/WFLY-4047 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final > Reporter: Wojciech Oczkowski > Assignee: Jason Greene > Attachments: TestWSJMS.zip > > > When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception: > 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72] > Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) > at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) > at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129) > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67) > at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? > at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115) > at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119) > at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49) > at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95) > at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895) > at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) > ... 13 more -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:13:35 2014 From: issues at jboss.org (Wojciech Oczkowski (JIRA)) Date: Mon, 3 Nov 2014 08:13:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4047) SLSB with WebService Annotation generates duplicate endpoint when JMS transport used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wojciech Oczkowski updated WFLY-4047: ------------------------------------- Description: When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception below. Simple project that reproduces this problem attached it requires additional Spring libraries for CXF and JMS transport. 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72] Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67) at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] ... 5 more Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115) at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119) at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49) at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95) at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895) at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) ... 13 more was: When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception: 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72] Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67) at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] ... 5 more Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115) at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119) at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49) at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95) at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895) at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) ... 13 more > SLSB with WebService Annotation generates duplicate endpoint when JMS transport used > ------------------------------------------------------------------------------------ > > Key: WFLY-4047 > URL: https://issues.jboss.org/browse/WFLY-4047 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final > Reporter: Wojciech Oczkowski > Assignee: Jason Greene > Attachments: TestWSJMS.zip > > > When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception below. Simple project that reproduces this problem attached it requires additional Spring libraries for CXF and JMS transport. > 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72] > Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) > at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) > at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129) > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67) > at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? > at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115) > at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119) > at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49) > at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95) > at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895) > at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) > ... 13 more -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:15:37 2014 From: issues at jboss.org (Wojciech Oczkowski (JIRA)) Date: Mon, 3 Nov 2014 08:15:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4047) SLSB with WebService Annotation generates duplicate endpoint when JMS transport used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wojciech Oczkowski updated WFLY-4047: ------------------------------------- Description: When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception below. Simple project that reproduces this problem attached (it requires additional Spring libraries for CXF and JMS transport). 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72] Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67) at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] ... 5 more Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115) at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119) at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49) at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95) at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895) at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) ... 13 more was: When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception below. Simple project that reproduces this problem attached it requires additional Spring libraries for CXF and JMS transport. 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72] Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129) at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67) at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] ... 5 more Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115) at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119) at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49) at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95) at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895) at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) ... 13 more > SLSB with WebService Annotation generates duplicate endpoint when JMS transport used > ------------------------------------------------------------------------------------ > > Key: WFLY-4047 > URL: https://issues.jboss.org/browse/WFLY-4047 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final > Reporter: Wojciech Oczkowski > Assignee: Jason Greene > Attachments: TestWSJMS.zip > > > When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception below. Simple project that reproduces this problem attached (it requires additional Spring libraries for CXF and JMS transport). > 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72] > Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) > at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) > at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129) > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67) > at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? > at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115) > at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119) > at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49) > at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95) > at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895) > at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) > ... 13 more -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:17:35 2014 From: issues at jboss.org (Wojciech Oczkowski (JIRA)) Date: Mon, 3 Nov 2014 08:17:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4047) SLSB with WebService Annotation generates duplicate endpoint when JMS transport used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016731#comment-13016731 ] Wojciech Oczkowski commented on WFLY-4047: ------------------------------------------ Workaround is to remove @Stateless annotation but what you've got then is just webservice endpoint without EJB Features like transactional processing for example. > SLSB with WebService Annotation generates duplicate endpoint when JMS transport used > ------------------------------------------------------------------------------------ > > Key: WFLY-4047 > URL: https://issues.jboss.org/browse/WFLY-4047 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final > Reporter: Wojciech Oczkowski > Assignee: Jason Greene > Attachments: TestWSJMS.zip > > > When deploying Webservice with JMS transport as Stateless Session Bean, 2 endpoint's are published. One is ok JMSDefaultEndpoind and second is HTTPDefaultEndpoint which is treated as JMS endpoind somehow and fails to deploy with exception below. Simple project that reproduces this problem attached (it requires additional Spring libraries for CXF and JMS transport). > 14:03:37,974 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."TestWSJMS-1.0-SNAPSHOT.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "TestWSJMS-1.0-SNAPSHOT.jar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_72] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_72] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_72] > Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) > at org.jboss.wsf.stack.cxf.deployment.EndpointImpl.doPublish(EndpointImpl.java:66) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) > at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) > at org.jboss.wsf.stack.cxf.configuration.NonSpringBusHolder.configure(NonSpringBusHolder.java:117) > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:129) > at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:67) > at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:75) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > Caused by: org.apache.cxf.configuration.ConfigurationException: Insufficient configuration for Destination. Did you configure a and set the jndiConnectionFactoryName ? > at org.apache.cxf.transport.jms.JMSConfiguration.ensureProperlyConfigured(JMSConfiguration.java:115) > at org.apache.cxf.transport.jms.JMSDestination.activate(JMSDestination.java:119) > at org.apache.cxf.transport.AbstractObservable.setMessageObserver(AbstractObservable.java:49) > at org.apache.cxf.binding.AbstractBaseBindingFactory.addListener(AbstractBaseBindingFactory.java:95) > at org.apache.cxf.binding.soap.SoapBindingFactory.addListener(SoapBindingFactory.java:895) > at org.apache.cxf.endpoint.ServerImpl.start(ServerImpl.java:131) > at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:362) > ... 13 more -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:20:35 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Mon, 3 Nov 2014 08:20:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016733#comment-13016733 ] Bela Ban commented on JGRP-1897: -------------------------------- OK, you're right; this won't work unless {{ENCRYPT}} is under {{UNICAST}}. But the latter is not feasible as it only works with a shared keystore. Can you create a pull request against master ? > ENCRYPT might drop messages during key change > --------------------------------------------- > > Key: JGRP-1897 > URL: https://issues.jboss.org/browse/JGRP-1897 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > Fix For: 3.6.1 > > > ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. > This problem was noticed while doing some stress testing on the fix for JGRP-1893. > When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. > We thought of possible solutions to be. > 1. Sender specific queue holding the messages received. > 2. Starting to queue up messages until new view has been received > I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. > I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:20:36 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Mon, 3 Nov 2014 08:20:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-1897: --------------------------- Fix Version/s: 3.6.1 > ENCRYPT might drop messages during key change > --------------------------------------------- > > Key: JGRP-1897 > URL: https://issues.jboss.org/browse/JGRP-1897 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > Fix For: 3.6.1 > > > ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. > This problem was noticed while doing some stress testing on the fix for JGRP-1893. > When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. > We thought of possible solutions to be. > 1. Sender specific queue holding the messages received. > 2. Starting to queue up messages until new view has been received > I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. > I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:21:36 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Mon, 3 Nov 2014 08:21:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1893) ENCRYPT: Thread safety issues during key changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-1893: --------------------------- Fix Version/s: 3.6.1 > ENCRYPT: Thread safety issues during key changes > ------------------------------------------------ > > Key: JGRP-1893 > URL: https://issues.jboss.org/browse/JGRP-1893 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > Fix For: 3.6.1 > > > For symmetric encryption, ENCRYPT has members with shared state: secret key, version and ciphers. In order for to provide consistent state between different threads accessing these members, they should be synchronized. > I have implemented one solution by wrapping the state in separate object which can be found here: > https://github.com/tepitebson/JGroups/tree/ENCRYPT_Thread_safety > I also have replaced the WeakHashMap holding the previous keys with Cache in google's guava library so my solution probably is not suitable for an official solution. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:42:35 2014 From: issues at jboss.org (Marek Goldmann (JIRA)) Date: Mon, 3 Nov 2014 08:42:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016742#comment-13016742 ] Marek Goldmann commented on WFLY-4044: -------------------------------------- I'll look into this. > Wildfly service will not start on fedora 20 - 64 bit > ---------------------------------------------------- > > Key: WFLY-4044 > URL: https://issues.jboss.org/browse/WFLY-4044 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Environment: Fedora 20 - updates installed > Reporter: Karl Nicholas > Assignee: Marek Goldmann > > standalone.sh starts wildfly ok but systemctl start service fails: > [root at localhost system]# yum install wildfly > Loaded plugins: langpacks, refresh-packagekit > Package wildfly-8.1.0-3.fc20.noarch already installed and latest version > Nothing to do > [root at localhost system]# systemctl start wildfly > [root at localhost system]# systemctl status wildfly > wildfly.service - The WildFly Application Server > Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) > Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago > Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) > Main PID: 7658 (code=exited, status=1/FAILURE) > Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. > Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE > Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. > [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:44:36 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 08:44:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4046) Container lifecycle event method invoked outside of extension observer method invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler updated WFLY-4046: --------------------------------- Description: Cannot deploy war that uses camel-cdi This works in 8.1.0.Final {code} org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) {code} Cross Issue: https://issues.apache.org/jira/browse/CAMEL-7992 was: Cannot deploy war that uses camel-cdi This works in 8.1.0.Final {code} org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) {code} > Container lifecycle event method invoked outside of extension observer method invocation > ---------------------------------------------------------------------------------------- > > Key: WFLY-4046 > URL: https://issues.jboss.org/browse/WFLY-4046 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Thomas Diesler > Assignee: Jozef Hartinger > > Cannot deploy war that uses camel-cdi > This works in 8.1.0.Final > {code} > org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. > at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) > at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) > at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) > at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) > at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) > {code} > Cross Issue: https://issues.apache.org/jira/browse/CAMEL-7992 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:50:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 08:50:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3978) PicketLink Subsystem EAP 6.4 Issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016749#comment-13016749 ] RH Bugzilla Integration commented on WFLY-3978: ----------------------------------------------- FIlip Bogyai changed the Status of [bug 1150639|https://bugzilla.redhat.com/show_bug.cgi?id=1150639] from ON_QA to VERIFIED > PicketLink Subsystem EAP 6.4 Issues > ----------------------------------- > > Key: WFLY-3978 > URL: https://issues.jboss.org/browse/WFLY-3978 > Project: WildFly > Issue Type: Task > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:50:36 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Mon, 3 Nov 2014 08:50:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4046) Container lifecycle event method invoked outside of extension observer method invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler reopened WFLY-4046: ---------------------------------- Can we please keep this open util it is resolved? Willem Jiang who maintains camel-cdi works for RedHat too. Let me talk to him to find out whether he knows what to do about this. Do you have a suggestion? > Container lifecycle event method invoked outside of extension observer method invocation > ---------------------------------------------------------------------------------------- > > Key: WFLY-4046 > URL: https://issues.jboss.org/browse/WFLY-4046 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Thomas Diesler > Assignee: Jozef Hartinger > > Cannot deploy war that uses camel-cdi > This works in 8.1.0.Final > {code} > org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. > at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) > at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) > at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) > at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) > at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) > {code} > Cross Issue: https://issues.apache.org/jira/browse/CAMEL-7992 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 08:57:35 2014 From: issues at jboss.org (Tero Leppikangas (JIRA)) Date: Mon, 3 Nov 2014 08:57:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016753#comment-13016753 ] Tero Leppikangas commented on JGRP-1897: ---------------------------------------- Hi. Created PRs for 3.4, 3.5 and master. Hopefully I did not mess up this time :) > ENCRYPT might drop messages during key change > --------------------------------------------- > > Key: JGRP-1897 > URL: https://issues.jboss.org/browse/JGRP-1897 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > Fix For: 3.6.1 > > > ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. > This problem was noticed while doing some stress testing on the fix for JGRP-1893. > When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. > We thought of possible solutions to be. > 1. Sender specific queue holding the messages received. > 2. Starting to queue up messages until new view has been received > I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. > I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 09:01:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 09:01:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3978) PicketLink Subsystem EAP 6.4 Issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016760#comment-13016760 ] RH Bugzilla Integration commented on WFLY-3978: ----------------------------------------------- FIlip Bogyai changed the Status of [bug 1151230|https://bugzilla.redhat.com/show_bug.cgi?id=1151230] from ON_QA to VERIFIED > PicketLink Subsystem EAP 6.4 Issues > ----------------------------------- > > Key: WFLY-3978 > URL: https://issues.jboss.org/browse/WFLY-3978 > Project: WildFly > Issue Type: Task > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 09:05:36 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 09:05:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-210) IO error during deployment scanning triggers undeployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-210: ------------------------------------ Fix Version/s: 1.0.0.Beta1 Assignee: Emmanuel Hugonnet (was: Jason Greene) Component/s: Domain Management (was: Server) > IO error during deployment scanning triggers undeployment > --------------------------------------------------------- > > Key: WFCORE-210 > URL: https://issues.jboss.org/browse/WFCORE-210 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: James Livingston > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Beta1 > > > If an IO error such as reaching the file descriptor limit occurs during deployment scanning, the scanner continues with an empty deployment list causing it to undeploy applications. > This occurs because FileSystemDeploymentService.scanDirectory() treats File.listFiles() returning null as an empty list rather than an error. http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 notes that it returns an empty array if the directory is empty, and null if it is not a directory or an IO error occurs. > It should instead respond to a null return value by aborting the scanner run, with a log message, and not proceed to undeploy applications. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 09:07:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 09:07:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-210) IO error during deployment scanning triggers undeployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016772#comment-13016772 ] RH Bugzilla Integration commented on WFCORE-210: ------------------------------------------------ Brian Stansberry changed the Status of [bug 1159709|https://bugzilla.redhat.com/show_bug.cgi?id=1159709] from NEW to ASSIGNED > IO error during deployment scanning triggers undeployment > --------------------------------------------------------- > > Key: WFCORE-210 > URL: https://issues.jboss.org/browse/WFCORE-210 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: James Livingston > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Beta1 > > > If an IO error such as reaching the file descriptor limit occurs during deployment scanning, the scanner continues with an empty deployment list causing it to undeploy applications. > This occurs because FileSystemDeploymentService.scanDirectory() treats File.listFiles() returning null as an empty list rather than an error. http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 notes that it returns an empty array if the directory is empty, and null if it is not a directory or an IO error occurs. > It should instead respond to a null return value by aborting the scanner run, with a log message, and not proceed to undeploy applications. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 09:13:36 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Mon, 3 Nov 2014 09:13:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016777#comment-13016777 ] Bela Ban commented on JGRP-1897: -------------------------------- I'm afraid you did ... :-) I don't mean to be a PITA, but your formatting essentially changed all lines in {{ENCRYPT}} ! Please keep the existing formatting and submit only the changes. > ENCRYPT might drop messages during key change > --------------------------------------------- > > Key: JGRP-1897 > URL: https://issues.jboss.org/browse/JGRP-1897 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > Fix For: 3.6.1 > > > ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. > This problem was noticed while doing some stress testing on the fix for JGRP-1893. > When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. > We thought of possible solutions to be. > 1. Sender specific queue holding the messages received. > 2. Starting to queue up messages until new view has been received > I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. > I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 09:27:35 2014 From: issues at jboss.org (Marek Goldmann (JIRA)) Date: Mon, 3 Nov 2014 09:27:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016791#comment-13016791 ] Marek Goldmann commented on WFLY-4044: -------------------------------------- I tried to reproduce this issue, but I cannot. I used a fresh system and installed wildfly. Everything works as advertised :) Please note that WildFly should never be started by hand when installed this way. This can cause permission issues (especially if you run it as root). Does {{/var/log/wildfly/standalone/server.log}} say anything after you run {{systemctl start wildfly}}? What does {{journalctl -u wildfly}} say? > Wildfly service will not start on fedora 20 - 64 bit > ---------------------------------------------------- > > Key: WFLY-4044 > URL: https://issues.jboss.org/browse/WFLY-4044 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Environment: Fedora 20 - updates installed > Reporter: Karl Nicholas > Assignee: Marek Goldmann > > standalone.sh starts wildfly ok but systemctl start service fails: > [root at localhost system]# yum install wildfly > Loaded plugins: langpacks, refresh-packagekit > Package wildfly-8.1.0-3.fc20.noarch already installed and latest version > Nothing to do > [root at localhost system]# systemctl start wildfly > [root at localhost system]# systemctl status wildfly > wildfly.service - The WildFly Application Server > Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) > Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago > Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) > Main PID: 7658 (code=exited, status=1/FAILURE) > Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. > Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE > Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. > [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 09:39:35 2014 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 3 Nov 2014 09:39:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-212) java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor In-Reply-To: References: Message-ID: Tomas Remes created WFCORE-212: ---------------------------------- Summary: java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor Key: WFCORE-212 URL: https://issues.jboss.org/browse/WFCORE-212 Project: WildFly Core Issue Type: Bug Components: Server Affects Versions: 1.0.0.Alpha9 Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20 Reporter: Tomas Remes Assignee: Jason Greene Following steps to reproduce section you will encounter this exception: {noformat} 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20] at org.jboss.as.controller.PathElement.(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184) at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20] {noformat} Note that the attached WAR works fine when the following is removed from ejb-jar.xml: {noformat} subscriptionDurability Durable {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 09:40:36 2014 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Mon, 3 Nov 2014 09:40:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-212) java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated WFCORE-212: ------------------------------- Attachment: test-jms.zip > java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-212 > URL: https://issues.jboss.org/browse/WFCORE-212 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha9 > Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20 > Reporter: Tomas Remes > Assignee: Jason Greene > Attachments: test-jms.zip > > > Following steps to reproduce section you will encounter this exception: > {noformat} > 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0 > at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20] > at org.jboss.as.controller.PathElement.(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184) > at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20] > {noformat} > Note that the attached WAR works fine when the following is removed from ejb-jar.xml: > {noformat} > > subscriptionDurability > Durable > > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 10:14:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 10:14:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4045) Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016818#comment-13016818 ] RH Bugzilla Integration commented on WFLY-4045: ----------------------------------------------- Kabir Khan changed the Status of [bug 1159814|https://bugzilla.redhat.com/show_bug.cgi?id=1159814] from NEW to MODIFIED > Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue > ------------------------------------------------------------------ > > Key: WFLY-4045 > URL: https://issues.jboss.org/browse/WFLY-4045 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > Add a regression test for https://issues.jboss.org/browse/WFCORE-190 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 10:24:36 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Mon, 3 Nov 2014 10:24:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet moved WFLY-122 to WFCORE-213: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-213 (was: WFLY-122) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Alpha11 1.0.0.Beta1 (was: 9.0.0.Beta1) > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha11, 1.0.0.Beta1 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 10:32:35 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Mon, 3 Nov 2014 10:32:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016825#comment-13016825 ] Paul Ferraro commented on WFLY-4037: ------------------------------------ Can you try to reproduce this with WF 9.0.0.Alpha1? There were significant changes made to batching/transactions with Infinispan since 8.1. If the requisite clustering modules are available, SSO will be backed by infinispan, but non-clustered. > Error 500 accessing png,css, rest > --------------------------------- > > Key: WFLY-4037 > URL: https://issues.jboss.org/browse/WFLY-4037 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Marcial Ati?nzar Navarro > Assignee: Paul Ferraro > Priority: Critical > > I've this error: > {code} > 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on. > at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275) > at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231) > at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225) > at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.CacheImpl.get(CacheImpl.java:377) > at org.infinispan.CacheImpl.get(CacheImpl.java:369) > at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271) > at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54) > at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34) > at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38) > at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50) > at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77) > at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 10:46:36 2014 From: issues at jboss.org (Karl Nicholas (JIRA)) Date: Mon, 3 Nov 2014 10:46:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016842#comment-13016842 ] Karl Nicholas commented on WFLY-4044: ------------------------------------- Well, are you saying that since I ran wildfly in standalone mode it breaks the systemctl mode? That kinda sucks. Can I uninstall it and reinstall it? journalctl: Nov 03 07:38:33 localhost.localdomain systemd[1]: Starting The WildFly Application Server... Nov 03 07:38:33 localhost.localdomain systemd[1]: Started The WildFly Application Server. Nov 03 07:38:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE Nov 03 07:38:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state server.log: 2014-11-01 14:56:05,899 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 14:56:06,279 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final 2014-11-01 14:56:06,399 INFO [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.1.0.Final "Kenny" starting 2014-11-01 14:56:06,410 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties: [Standalone] = awt.toolkit = sun.awt.X11.XToolkit file.encoding = UTF-8 file.encoding.pkg = sun.io file.separator = / java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment java.awt.headless = true java.awt.printerjob = sun.print.PSPrinterJob java.class.path = /usr/share/wildfly/jboss-modules.jar java.class.version = 51.0 java.endorsed.dirs = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/endorsed java.ext.dirs = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/ext:/usr/java/packages/lib/ext java.home = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre java.io.tmpdir = /tmp java.library.path = /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib java.net.preferIPv4Stack = true java.runtime.name = OpenJDK Runtime Environment java.runtime.version = 1.7.0_71-mockbuild_2014_10_15_17_02-b00 java.specification.name = Java Platform API Specification java.specification.vendor = Oracle Corporation java.specification.version = 1.7 java.util.logging.manager = org.jboss.logmanager.LogManager java.vendor = Oracle Corporation java.vendor.url = http://java.oracle.com/ java.vendor.url.bug = http://bugreport.sun.com/bugreport/ java.version = 1.7.0_71 java.vm.info = mixed mode java.vm.name = OpenJDK 64-Bit Server VM java.vm.specification.name = Java Virtual Machine Specification java.vm.specification.vendor = Oracle Corporation java.vm.specification.version = 1.7 java.vm.vendor = Oracle Corporation java.vm.version = 24.65-b04 javax.management.builder.initial = org.jboss.as.jmx.PluggableMBeanServerBuilder javax.xml.datatype.DatatypeFactory = __redirected.__DatatypeFactory javax.xml.parsers.DocumentBuilderFactory = __redirected.__DocumentBuilderFactory javax.xml.parsers.SAXParserFactory = __redirected.__SAXParserFactory javax.xml.stream.XMLEventFactory = __redirected.__XMLEventFactory javax.xml.stream.XMLInputFactory = __redirected.__XMLInputFactory javax.xml.stream.XMLOutputFactory = __redirected.__XMLOutputFactory javax.xml.transform.TransformerFactory = __redirected.__TransformerFactory javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema = __redirected.__SchemaFactory javax.xml.xpath.XPathFactory:http://java.sun.com/jaxp/xpath/dom = __redirected.__XPathFactory jboss.home.dir = /usr/share/wildfly jboss.host.name = localhost jboss.modules.dir = /usr/share/wildfly/modules jboss.modules.system.pkgs = org.jboss.byteman jboss.node.name = localhost jboss.qualified.host.name = localhost.localdomain jboss.server.base.dir = /usr/share/wildfly/standalone jboss.server.config.dir = /usr/share/wildfly/standalone/configuration jboss.server.data.dir = /usr/share/wildfly/standalone/data jboss.server.deploy.dir = /usr/share/wildfly/standalone/data/content jboss.server.log.dir = /usr/share/wildfly/standalone/log jboss.server.name = localhost jboss.server.persist.config = true jboss.server.temp.dir = /usr/share/wildfly/standalone/tmp line.separator = logging.configuration = file:/usr/share/wildfly/standalone/configuration/logging.properties module.path = /usr/share/wildfly/modules org.jboss.boot.log.file = /usr/share/wildfly/standalone/log/server.log org.jboss.resolver.warning = true org.xml.sax.driver = __redirected.__XMLReaderFactory os.arch = amd64 os.name = Linux os.version = 3.16.6-203.fc20.x86_64 path.separator = : sun.arch.data.model = 64 sun.boot.class.path = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/resources.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/rt.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/jsse.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/jce.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/charsets.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/rhino.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/jfr.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/classes sun.boot.library.path = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/amd64 sun.cpu.endian = little sun.cpu.isalist = sun.io.unicode.encoding = UnicodeLittle sun.java.command = /usr/share/wildfly/jboss-modules.jar -mp /usr/share/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/usr/share/wildfly -Djboss.server.base.dir=/usr/share/wildfly/standalone sun.java.launcher = SUN_STANDARD sun.jnu.encoding = UTF-8 sun.management.compiler = HotSpot 64-Bit Tiered Compilers sun.os.patch.level = unknown user.country = US user.dir = /usr/share/wildfly/bin user.home = /root user.language = en user.name = root user.timezone = America/Los_Angeles 2014-11-01 14:56:06,414 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/usr/share/wildfly/standalone/log/server.log -Dlogging.configuration=file:/usr/share/wildfly/standalone/configuration/logging.properties 2014-11-01 14:56:07,675 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http) 2014-11-01 14:56:07,701 INFO [org.xnio] (MSC service thread 1-3) XNIO version 3.2.2.Final 2014-11-01 14:56:07,715 INFO [org.xnio.nio] (MSC service thread 1-3) XNIO NIO Implementation Version 3.2.2.Final 2014-11-01 14:56:07,768 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 32) JBAS010280: Activating Infinispan subsystem. 2014-11-01 14:56:07,773 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 31) WFLYIO001: Worker 'default' has auto-configured to 8 core threads with 64 task threads based on your 4 available processors 2014-11-01 14:56:07,791 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 38) JBAS012615: Activated the following JSF Implementations: [main] 2014-11-01 14:56:07,792 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 40) JBAS011800: Activating Naming Subsystem 2014-11-01 14:56:07,817 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 46) JBAS010153: Node identifier property is set to the default value. Please make sure it is unique. 2014-11-01 14:56:07,825 INFO [org.jboss.as.security] (ServerService Thread Pool -- 45) JBAS013171: Activating Security Subsystem 2014-11-01 14:56:07,827 INFO [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 4.0.3.Final 2014-11-01 14:56:07,856 INFO [org.jboss.as.security] (MSC service thread 1-7) JBAS013170: Current PicketBox version=4.0.21.Beta1 2014-11-01 14:56:07,874 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 27) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) 2014-11-01 14:56:07,891 INFO [org.jboss.as.naming] (MSC service thread 1-6) JBAS011802: Starting Naming Service 2014-11-01 14:56:07,892 INFO [org.jboss.as.mail.extension] (MSC service thread 1-4) JBAS015400: Bound mail session [java:jboss/mail/Default] 2014-11-01 14:56:07,908 INFO [org.jboss.as.connector.logging] (MSC service thread 1-6) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.3.Final) 2014-11-01 14:56:07,919 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) JBAS010417: Started Driver service with driver-name = h2 2014-11-01 14:56:07,939 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 48) JBAS015537: Activating WebServices Extension 2014-11-01 14:56:08,000 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.15.Final starting 2014-11-01 14:56:08,008 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 47) JBAS017502: Undertow 1.0.15.Final starting 2014-11-01 14:56:08,470 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 47) JBAS017527: Creating file handler for path /usr/share/wildfly/welcome-content 2014-11-01 14:56:08,477 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017525: Started server default-server. 2014-11-01 14:56:08,508 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017531: Host default-host starting 2014-11-01 14:56:08,584 WARN [org.jboss.as.webservices] (ServerService Thread Pool -- 48) JBAS015506: Cannot load WS deployment aspects from /META-INF/stack-specific-deployment-aspects.xml 2014-11-01 14:56:08,638 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080 2014-11-01 14:56:08,714 INFO [org.jboss.ws.common.management] (MSC service thread 1-8) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.0.Final 2014-11-01 14:56:08,934 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS] 2014-11-01 14:56:09,004 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-6) JBAS015012: Started FileSystemDeploymentService for directory /usr/share/wildfly/standalone/deployments 2014-11-01 14:56:09,006 ERROR [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-5) JBAS015102: Unable to load console module for slot main, disabling console 2014-11-01 14:56:09,252 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management 2014-11-01 14:56:09,254 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990 2014-11-01 14:56:09,255 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.1.0.Final "Kenny" started in 3762ms - Started 184 of 233 services (81 services are lazy, passive or on-demand) 2014-11-01 14:56:16,022 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010409: Unbound data source [java:jboss/datasources/ExampleDS] 2014-11-01 14:56:16,025 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017532: Host default-host stopping 2014-11-01 14:56:16,034 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) JBAS010418: Stopped Driver service with driver-name = h2 2014-11-01 14:56:16,038 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017521: Undertow HTTP listener default suspending 2014-11-01 14:56:16,039 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017520: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080 2014-11-01 14:56:16,041 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017506: Undertow 1.0.15.Final stopping 2014-11-01 14:56:16,052 INFO [org.jboss.as] (MSC service thread 1-5) JBAS015950: WildFly 8.1.0.Final "Kenny" stopped in 40ms 2014-11-01 15:06:09,117 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 15:11:07,061 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 15:11:45,931 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 15:15:58,565 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 15:16:56,941 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 15:17:03,849 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final > Wildfly service will not start on fedora 20 - 64 bit > ---------------------------------------------------- > > Key: WFLY-4044 > URL: https://issues.jboss.org/browse/WFLY-4044 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Environment: Fedora 20 - updates installed > Reporter: Karl Nicholas > Assignee: Marek Goldmann > > standalone.sh starts wildfly ok but systemctl start service fails: > [root at localhost system]# yum install wildfly > Loaded plugins: langpacks, refresh-packagekit > Package wildfly-8.1.0-3.fc20.noarch already installed and latest version > Nothing to do > [root at localhost system]# systemctl start wildfly > [root at localhost system]# systemctl status wildfly > wildfly.service - The WildFly Application Server > Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) > Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago > Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) > Main PID: 7658 (code=exited, status=1/FAILURE) > Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. > Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE > Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. > [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 11:43:35 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 3 Nov 2014 11:43:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016863#comment-13016863 ] Tomaz Cerar commented on WFLY-4044: ----------------------------------- No you can run it directly by invoking standalone.sh but make sure you do so under same username as you use it for running the service. Otherwise it will screw up your permissions. you can fix that by running {noformat}chown -R wildfly-service-username:wildfly-service-group /usr/share/wildfly {noformat} probably {noformat}chown -R wildfly:wildfly /usr/share/wildfly {noformat} > Wildfly service will not start on fedora 20 - 64 bit > ---------------------------------------------------- > > Key: WFLY-4044 > URL: https://issues.jboss.org/browse/WFLY-4044 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Environment: Fedora 20 - updates installed > Reporter: Karl Nicholas > Assignee: Marek Goldmann > > standalone.sh starts wildfly ok but systemctl start service fails: > [root at localhost system]# yum install wildfly > Loaded plugins: langpacks, refresh-packagekit > Package wildfly-8.1.0-3.fc20.noarch already installed and latest version > Nothing to do > [root at localhost system]# systemctl start wildfly > [root at localhost system]# systemctl status wildfly > wildfly.service - The WildFly Application Server > Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) > Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago > Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) > Main PID: 7658 (code=exited, status=1/FAILURE) > Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. > Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE > Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. > [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 11:47:35 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 3 Nov 2014 11:47:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016865#comment-13016865 ] Tomaz Cerar commented on WFLY-4037: ----------------------------------- No cluster is not activated by default, you probably have tag in your web.xml which tells server that it needs to cluster it. > Error 500 accessing png,css, rest > --------------------------------- > > Key: WFLY-4037 > URL: https://issues.jboss.org/browse/WFLY-4037 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Marcial Ati?nzar Navarro > Assignee: Paul Ferraro > Priority: Critical > > I've this error: > {code} > 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on. > at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275) > at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231) > at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225) > at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.CacheImpl.get(CacheImpl.java:377) > at org.infinispan.CacheImpl.get(CacheImpl.java:369) > at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271) > at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54) > at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34) > at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38) > at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50) > at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77) > at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 12:11:36 2014 From: issues at jboss.org (=?UTF-8?Q?Marcial_Ati=C3=A9nzar_Navarro_=28JIRA=29?=) Date: Mon, 3 Nov 2014 12:11:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016875#comment-13016875 ] Marcial Ati?nzar Navarro commented on WFLY-4037: ------------------------------------------------ Not: {code} matienzar at matienzar:/opt/workspace$ grep --include=\*.xml -rnw '/opt/workspace' -e 'distributable' matienzar at matienzar:/opt/workspace$ {code} > Error 500 accessing png,css, rest > --------------------------------- > > Key: WFLY-4037 > URL: https://issues.jboss.org/browse/WFLY-4037 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Marcial Ati?nzar Navarro > Assignee: Paul Ferraro > Priority: Critical > > I've this error: > {code} > 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on. > at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275) > at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231) > at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225) > at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.CacheImpl.get(CacheImpl.java:377) > at org.infinispan.CacheImpl.get(CacheImpl.java:369) > at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271) > at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54) > at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34) > at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38) > at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50) > at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77) > at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 12:31:56 2014 From: issues at jboss.org (Karl Nicholas (JIRA)) Date: Mon, 3 Nov 2014 12:31:56 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016842#comment-13016842 ] Karl Nicholas edited comment on WFLY-4044 at 11/3/14 12:31 PM: --------------------------------------------------------------- Well, are you saying that since I ran wildfly in standalone mode it breaks the systemctl mode? That kinda sucks. Can I uninstall it and reinstall it? journalctl: Nov 03 07:38:33 localhost.localdomain systemd[1]: Starting The WildFly Application Server... Nov 03 07:38:33 localhost.localdomain systemd[1]: Started The WildFly Application Server. Nov 03 07:38:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE Nov 03 07:38:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state was (Author: karlnicholas): Well, are you saying that since I ran wildfly in standalone mode it breaks the systemctl mode? That kinda sucks. Can I uninstall it and reinstall it? journalctl: Nov 03 07:38:33 localhost.localdomain systemd[1]: Starting The WildFly Application Server... Nov 03 07:38:33 localhost.localdomain systemd[1]: Started The WildFly Application Server. Nov 03 07:38:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE Nov 03 07:38:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state server.log: 2014-11-01 14:56:05,899 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 14:56:06,279 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final 2014-11-01 14:56:06,399 INFO [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.1.0.Final "Kenny" starting 2014-11-01 14:56:06,410 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties: [Standalone] = awt.toolkit = sun.awt.X11.XToolkit file.encoding = UTF-8 file.encoding.pkg = sun.io file.separator = / java.awt.graphicsenv = sun.awt.X11GraphicsEnvironment java.awt.headless = true java.awt.printerjob = sun.print.PSPrinterJob java.class.path = /usr/share/wildfly/jboss-modules.jar java.class.version = 51.0 java.endorsed.dirs = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/endorsed java.ext.dirs = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/ext:/usr/java/packages/lib/ext java.home = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre java.io.tmpdir = /tmp java.library.path = /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib java.net.preferIPv4Stack = true java.runtime.name = OpenJDK Runtime Environment java.runtime.version = 1.7.0_71-mockbuild_2014_10_15_17_02-b00 java.specification.name = Java Platform API Specification java.specification.vendor = Oracle Corporation java.specification.version = 1.7 java.util.logging.manager = org.jboss.logmanager.LogManager java.vendor = Oracle Corporation java.vendor.url = http://java.oracle.com/ java.vendor.url.bug = http://bugreport.sun.com/bugreport/ java.version = 1.7.0_71 java.vm.info = mixed mode java.vm.name = OpenJDK 64-Bit Server VM java.vm.specification.name = Java Virtual Machine Specification java.vm.specification.vendor = Oracle Corporation java.vm.specification.version = 1.7 java.vm.vendor = Oracle Corporation java.vm.version = 24.65-b04 javax.management.builder.initial = org.jboss.as.jmx.PluggableMBeanServerBuilder javax.xml.datatype.DatatypeFactory = __redirected.__DatatypeFactory javax.xml.parsers.DocumentBuilderFactory = __redirected.__DocumentBuilderFactory javax.xml.parsers.SAXParserFactory = __redirected.__SAXParserFactory javax.xml.stream.XMLEventFactory = __redirected.__XMLEventFactory javax.xml.stream.XMLInputFactory = __redirected.__XMLInputFactory javax.xml.stream.XMLOutputFactory = __redirected.__XMLOutputFactory javax.xml.transform.TransformerFactory = __redirected.__TransformerFactory javax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema = __redirected.__SchemaFactory javax.xml.xpath.XPathFactory:http://java.sun.com/jaxp/xpath/dom = __redirected.__XPathFactory jboss.home.dir = /usr/share/wildfly jboss.host.name = localhost jboss.modules.dir = /usr/share/wildfly/modules jboss.modules.system.pkgs = org.jboss.byteman jboss.node.name = localhost jboss.qualified.host.name = localhost.localdomain jboss.server.base.dir = /usr/share/wildfly/standalone jboss.server.config.dir = /usr/share/wildfly/standalone/configuration jboss.server.data.dir = /usr/share/wildfly/standalone/data jboss.server.deploy.dir = /usr/share/wildfly/standalone/data/content jboss.server.log.dir = /usr/share/wildfly/standalone/log jboss.server.name = localhost jboss.server.persist.config = true jboss.server.temp.dir = /usr/share/wildfly/standalone/tmp line.separator = logging.configuration = file:/usr/share/wildfly/standalone/configuration/logging.properties module.path = /usr/share/wildfly/modules org.jboss.boot.log.file = /usr/share/wildfly/standalone/log/server.log org.jboss.resolver.warning = true org.xml.sax.driver = __redirected.__XMLReaderFactory os.arch = amd64 os.name = Linux os.version = 3.16.6-203.fc20.x86_64 path.separator = : sun.arch.data.model = 64 sun.boot.class.path = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/resources.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/rt.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/jsse.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/jce.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/charsets.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/rhino.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/jfr.jar:/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/classes sun.boot.library.path = /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc20.x86_64/jre/lib/amd64 sun.cpu.endian = little sun.cpu.isalist = sun.io.unicode.encoding = UnicodeLittle sun.java.command = /usr/share/wildfly/jboss-modules.jar -mp /usr/share/wildfly/modules org.jboss.as.standalone -Djboss.home.dir=/usr/share/wildfly -Djboss.server.base.dir=/usr/share/wildfly/standalone sun.java.launcher = SUN_STANDARD sun.jnu.encoding = UTF-8 sun.management.compiler = HotSpot 64-Bit Tiered Compilers sun.os.patch.level = unknown user.country = US user.dir = /usr/share/wildfly/bin user.home = /root user.language = en user.name = root user.timezone = America/Los_Angeles 2014-11-01 14:56:06,414 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -agentpath:/usr/lib64/libabrt-java-connector.so=abrt=on -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Dorg.jboss.boot.log.file=/usr/share/wildfly/standalone/log/server.log -Dlogging.configuration=file:/usr/share/wildfly/standalone/configuration/logging.properties 2014-11-01 14:56:07,675 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http) 2014-11-01 14:56:07,701 INFO [org.xnio] (MSC service thread 1-3) XNIO version 3.2.2.Final 2014-11-01 14:56:07,715 INFO [org.xnio.nio] (MSC service thread 1-3) XNIO NIO Implementation Version 3.2.2.Final 2014-11-01 14:56:07,768 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 32) JBAS010280: Activating Infinispan subsystem. 2014-11-01 14:56:07,773 INFO [org.wildfly.extension.io] (ServerService Thread Pool -- 31) WFLYIO001: Worker 'default' has auto-configured to 8 core threads with 64 task threads based on your 4 available processors 2014-11-01 14:56:07,791 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 38) JBAS012615: Activated the following JSF Implementations: [main] 2014-11-01 14:56:07,792 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 40) JBAS011800: Activating Naming Subsystem 2014-11-01 14:56:07,817 WARN [org.jboss.as.txn] (ServerService Thread Pool -- 46) JBAS010153: Node identifier property is set to the default value. Please make sure it is unique. 2014-11-01 14:56:07,825 INFO [org.jboss.as.security] (ServerService Thread Pool -- 45) JBAS013171: Activating Security Subsystem 2014-11-01 14:56:07,827 INFO [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 4.0.3.Final 2014-11-01 14:56:07,856 INFO [org.jboss.as.security] (MSC service thread 1-7) JBAS013170: Current PicketBox version=4.0.21.Beta1 2014-11-01 14:56:07,874 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 27) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3) 2014-11-01 14:56:07,891 INFO [org.jboss.as.naming] (MSC service thread 1-6) JBAS011802: Starting Naming Service 2014-11-01 14:56:07,892 INFO [org.jboss.as.mail.extension] (MSC service thread 1-4) JBAS015400: Bound mail session [java:jboss/mail/Default] 2014-11-01 14:56:07,908 INFO [org.jboss.as.connector.logging] (MSC service thread 1-6) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.3.Final) 2014-11-01 14:56:07,919 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) JBAS010417: Started Driver service with driver-name = h2 2014-11-01 14:56:07,939 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 48) JBAS015537: Activating WebServices Extension 2014-11-01 14:56:08,000 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS017502: Undertow 1.0.15.Final starting 2014-11-01 14:56:08,008 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 47) JBAS017502: Undertow 1.0.15.Final starting 2014-11-01 14:56:08,470 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 47) JBAS017527: Creating file handler for path /usr/share/wildfly/welcome-content 2014-11-01 14:56:08,477 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017525: Started server default-server. 2014-11-01 14:56:08,508 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017531: Host default-host starting 2014-11-01 14:56:08,584 WARN [org.jboss.as.webservices] (ServerService Thread Pool -- 48) JBAS015506: Cannot load WS deployment aspects from /META-INF/stack-specific-deployment-aspects.xml 2014-11-01 14:56:08,638 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080 2014-11-01 14:56:08,714 INFO [org.jboss.ws.common.management] (MSC service thread 1-8) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.2.0.Final 2014-11-01 14:56:08,934 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS] 2014-11-01 14:56:09,004 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-6) JBAS015012: Started FileSystemDeploymentService for directory /usr/share/wildfly/standalone/deployments 2014-11-01 14:56:09,006 ERROR [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-5) JBAS015102: Unable to load console module for slot main, disabling console 2014-11-01 14:56:09,252 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management 2014-11-01 14:56:09,254 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990 2014-11-01 14:56:09,255 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.1.0.Final "Kenny" started in 3762ms - Started 184 of 233 services (81 services are lazy, passive or on-demand) 2014-11-01 14:56:16,022 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010409: Unbound data source [java:jboss/datasources/ExampleDS] 2014-11-01 14:56:16,025 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017532: Host default-host stopping 2014-11-01 14:56:16,034 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) JBAS010418: Stopped Driver service with driver-name = h2 2014-11-01 14:56:16,038 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017521: Undertow HTTP listener default suspending 2014-11-01 14:56:16,039 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017520: Undertow HTTP listener default stopped, was bound to /127.0.0.1:8080 2014-11-01 14:56:16,041 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017506: Undertow 1.0.15.Final stopping 2014-11-01 14:56:16,052 INFO [org.jboss.as] (MSC service thread 1-5) JBAS015950: WildFly 8.1.0.Final "Kenny" stopped in 40ms 2014-11-01 15:06:09,117 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 15:11:07,061 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 15:11:45,931 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 15:15:58,565 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 15:16:56,941 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final 2014-11-01 15:17:03,849 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final > Wildfly service will not start on fedora 20 - 64 bit > ---------------------------------------------------- > > Key: WFLY-4044 > URL: https://issues.jboss.org/browse/WFLY-4044 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Environment: Fedora 20 - updates installed > Reporter: Karl Nicholas > Assignee: Marek Goldmann > > standalone.sh starts wildfly ok but systemctl start service fails: > [root at localhost system]# yum install wildfly > Loaded plugins: langpacks, refresh-packagekit > Package wildfly-8.1.0-3.fc20.noarch already installed and latest version > Nothing to do > [root at localhost system]# systemctl start wildfly > [root at localhost system]# systemctl status wildfly > wildfly.service - The WildFly Application Server > Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) > Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago > Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) > Main PID: 7658 (code=exited, status=1/FAILURE) > Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. > Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE > Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. > [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 12:33:36 2014 From: issues at jboss.org (Karl Nicholas (JIRA)) Date: Mon, 3 Nov 2014 12:33:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016878#comment-13016878 ] Karl Nicholas commented on WFLY-4044: ------------------------------------- I reinstalled Fedora, updated, and installed Wildfly 8.1.0.Final and ran it only with "sudo systemctl start wildfly" and it seems to be running fine. Not being able to run it standalone seems like a warning that should be pretty clearly stated somewhere obvious. Anyway, thanks for the assistance, I recommend closing this issue. > Wildfly service will not start on fedora 20 - 64 bit > ---------------------------------------------------- > > Key: WFLY-4044 > URL: https://issues.jboss.org/browse/WFLY-4044 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Environment: Fedora 20 - updates installed > Reporter: Karl Nicholas > Assignee: Marek Goldmann > > standalone.sh starts wildfly ok but systemctl start service fails: > [root at localhost system]# yum install wildfly > Loaded plugins: langpacks, refresh-packagekit > Package wildfly-8.1.0-3.fc20.noarch already installed and latest version > Nothing to do > [root at localhost system]# systemctl start wildfly > [root at localhost system]# systemctl status wildfly > wildfly.service - The WildFly Application Server > Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) > Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago > Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) > Main PID: 7658 (code=exited, status=1/FAILURE) > Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. > Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE > Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. > [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 12:38:36 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Mon, 3 Nov 2014 12:38:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-117) Support for SSL/TLS protocol and algorithm filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd reassigned ELY-117: ------------------------------- Assignee: David Lloyd I quite unexpectedly found myself working on this, so I'll finish it up. > Support for SSL/TLS protocol and algorithm filtering > ---------------------------------------------------- > > Key: ELY-117 > URL: https://issues.jboss.org/browse/ELY-117 > Project: WildFly Elytron > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.0.0.Beta1 > > > Support OpenSSL-style filter expressions. Consider the following prior work for reference: > * The GrokTLS project: https://github.com/timw/groktls > * Previous unmerged enhancement to XNIO: https://github.com/xnio/xnio/pull/56 > * APR/Native connector docs - http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL_Support_-_APR/Native > * OpenSSL docs: > ** https://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS > ** https://www.openssl.org/docs/apps/ciphers.html#CIPHER_SUITE_NAMES (note that the OpenSSL names are non-standard) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 12:47:36 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Mon, 3 Nov 2014 12:47:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet updated WFCORE-213: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/284 (was: https://github.com/wildfly/wildfly-core/pull/237) > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha11, 1.0.0.Beta1 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 14:35:36 2014 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Mon, 3 Nov 2014 14:35:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1077) JDK ORB Subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016909#comment-13016909 ] Tomasz Adamski commented on WFLY-1077: -------------------------------------- JBoss EAP (Jacorb) <-> Wildfly (IIOP-OpenJDK) compatibility test Configuration: Web application consisting of secure servlet and transactional EJB deployed on server A. EAR with transaction EJB deployed on server B. Execution: 1. User opens web browser and authenicates using basic logging. 2. Bean on server A authenticates Principal. 3. Bean on server A starts JTS transaction. 4. Bean on server A invokes remotely (using iiop) bean on server B. 5. Bean on server B authenicates Principal. 6. Bean on server B checks that transaction is present. Result: I have run the test in both jboss-eap=A;wildfly=B and jboss-eap=B;wildfly=A configuration. In both cases SASContext and transaction context are propagated correctly. Principal and transaction are propagated to bean B. > JDK ORB Subsystem > ----------------- > > Key: WFLY-1077 > URL: https://issues.jboss.org/browse/WFLY-1077 > Project: WildFly > Issue Type: Feature Request > Components: IIOP > Reporter: Dimitris Andreadis > Assignee: Tomasz Adamski > > Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem. > AFAIK, most/all JDK ORBs are based on the Sun ORB. > Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 15:51:35 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 15:51:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-214) Missing jboss-threads in jboss-cli-client.jar In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-214: --------------------------------------- Summary: Missing jboss-threads in jboss-cli-client.jar Key: WFCORE-214 URL: https://issues.jboss.org/browse/WFCORE-214 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry The client jar jboss-cli-client.jar is missing the org.jboss.threads classes, even though those are a dep of ModelControllerClient. Perhaps the CLI's call paths don't use those classes, but that's an accident waiting to happen, plus it prevents use of this jar as a general purpose management client, when otherwise it could be used that way. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 15:52:35 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 15:52:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-214) Missing jboss-threads in jboss-cli-client.jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry closed WFCORE-214. ----------------------------------- Resolution: Done It's there. Never mind. > Missing jboss-threads in jboss-cli-client.jar > --------------------------------------------- > > Key: WFCORE-214 > URL: https://issues.jboss.org/browse/WFCORE-214 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > The client jar jboss-cli-client.jar is missing the org.jboss.threads classes, even though those are a dep of ModelControllerClient. > Perhaps the CLI's call paths don't use those classes, but that's an accident waiting to happen, plus it prevents use of this jar as a general purpose management client, when otherwise it could be used that way. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 17:20:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 17:20:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-205) ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016949#comment-13016949 ] RH Bugzilla Integration commented on WFCORE-205: ------------------------------------------------ Paul Gier changed the Status of [bug 1078062|https://bugzilla.redhat.com/show_bug.cgi?id=1078062] from MODIFIED to ON_QA > ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content > --------------------------------------------------------------------------------------------- > > Key: WFCORE-205 > URL: https://issues.jboss.org/browse/WFCORE-205 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha11 > > > ManagedDMRContentTypeResource.content is used for generating an overall hash for the stored content, but it does not use consistent ordering (i.e. it needs to be a LinkedHashMap or perhaps a TreeMap.) The result is when another node in the domain receives an update it may calculate a different overall hash. > This is surfacing as failures in https://bugzilla.redhat.com/show_bug.cgi?id=1078062 when the master and slave are running on different JVM releases. Different VM releases often have different ordering behavior when iterating over the unordered collections. > I believe this is unlikely to result in real-world problems since any backup will persist its own version of the hash to its local copy of domain.xml, so there won't be any mismatch. The importance of the overall hash is that it allows the process to find the content in the repo when it is added. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 17:20:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 17:20:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3900) Unable to inject EJB Context into CDI Interceptor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016951#comment-13016951 ] RH Bugzilla Integration commented on WFLY-3900: ----------------------------------------------- Paul Gier changed the Status of [bug 1149644|https://bugzilla.redhat.com/show_bug.cgi?id=1149644] from MODIFIED to ON_QA > Unable to inject EJB Context into CDI Interceptor > ------------------------------------------------- > > Key: WFLY-3900 > URL: https://issues.jboss.org/browse/WFLY-3900 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > Attachments: inject-ejb-context-into-cdi-interceptor.jar, server.log > > > CDI Interceptor cannot inject EJB session context. > If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject. > See attached reproducer with source and log file. > private @Resource SessionContext sessionContext; > Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185) > ... 127 more -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 17:20:45 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 17:20:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-950) RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016962#comment-13016962 ] RH Bugzilla Integration commented on WFLY-950: ---------------------------------------------- Paul Gier changed the Status of [bug 899666|https://bugzilla.redhat.com/show_bug.cgi?id=899666] from MODIFIED to ON_QA > RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception > --------------------------------------------------------------------- > > Key: WFLY-950 > URL: https://issues.jboss.org/browse/WFLY-950 > Project: WildFly > Issue Type: Bug > Components: REST > Reporter: Pavel Janousek > Assignee: Weinan Li > > RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. The major one (also portable defined by JAX-RS standard) is _javax.ws.rs.Application_. When I set this parameter to empty content present behavior is raising exception "java.lang.StringIndexOutOfBoundsException: String index out of range: 0", it is not so good. > I think, this is hard miss-configuration error and deployment description as this one should be rejected and a such application should not be deployed at all with appropriate error message, but not only by messed exception. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 17:20:45 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 17:20:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3998) Add option to define enabled cipher suites within SSL definitions in security realms. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016964#comment-13016964 ] RH Bugzilla Integration commented on WFLY-3998: ----------------------------------------------- Paul Gier changed the Status of [bug 1153854|https://bugzilla.redhat.com/show_bug.cgi?id=1153854] from MODIFIED to ON_QA > Add option to define enabled cipher suites within SSL definitions in security realms. > ------------------------------------------------------------------------------------- > > Key: WFLY-3998 > URL: https://issues.jboss.org/browse/WFLY-3998 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 17:20:46 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 17:20:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3993) Add attribute to specify enabled-protocols for HTTPS within domain management. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016965#comment-13016965 ] RH Bugzilla Integration commented on WFLY-3993: ----------------------------------------------- Paul Gier changed the Status of [bug 1153854|https://bugzilla.redhat.com/show_bug.cgi?id=1153854] from MODIFIED to ON_QA > Add attribute to specify enabled-protocols for HTTPS within domain management. > ------------------------------------------------------------------------------ > > Key: WFLY-3993 > URL: https://issues.jboss.org/browse/WFLY-3993 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 17:20:46 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 17:20:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-180) Add attribute to specify enabled-protocols for HTTPS within domain management. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016966#comment-13016966 ] RH Bugzilla Integration commented on WFCORE-180: ------------------------------------------------ Paul Gier changed the Status of [bug 1153854|https://bugzilla.redhat.com/show_bug.cgi?id=1153854] from MODIFIED to ON_QA > Add attribute to specify enabled-protocols for HTTPS within domain management. > ------------------------------------------------------------------------------ > > Key: WFCORE-180 > URL: https://issues.jboss.org/browse/WFCORE-180 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.0.0.Alpha11 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 17:20:47 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 17:20:47 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-182) provide means to specify allowed ciphers for management https or change default to exclude weak ciphers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016967#comment-13016967 ] RH Bugzilla Integration commented on WFCORE-182: ------------------------------------------------ Paul Gier changed the Status of [bug 1153854|https://bugzilla.redhat.com/show_bug.cgi?id=1153854] from MODIFIED to ON_QA > provide means to specify allowed ciphers for management https or change default to exclude weak ciphers > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-182 > URL: https://issues.jboss.org/browse/WFCORE-182 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: R Stokoe > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha11 > > > Provide means to specify allowed ciphers for management https. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 17:20:48 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 17:20:48 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3974) Move 'Channel end notification received, closing channel' to DEBUG In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016972#comment-13016972 ] RH Bugzilla Integration commented on WFLY-3974: ----------------------------------------------- Paul Gier changed the Status of [bug 1153281|https://bugzilla.redhat.com/show_bug.cgi?id=1153281] from MODIFIED to ON_QA > Move 'Channel end notification received, closing channel' to DEBUG > ------------------------------------------------------------------ > > Key: WFLY-3974 > URL: https://issues.jboss.org/browse/WFLY-3974 > Project: WildFly > Issue Type: Enhancement > Components: Naming > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 9.0.0.Beta1 > > > When a remote jms queue is located the following is seen: > 2014-09-25 16:48:29,327 INFO [org.jboss.as.naming] (Remoting "jeev6dev01_200" task-1) JBAS011806: Notification de fin de canal re?ue, fermeture du canal Channel ID 0cb79bd5 (inbound) of Remoting connection 53a1933a to /10.23.132.245:57733 > This is due to org.jboss.as.naming.NamingLogger where the following is used: > @LogMessage(level=Logger.Level.INFO) > @Message(id=11806, value="Channel end notification received, closing channel %s") > public abstract void closingChannelOnChannelEnd(Channel paramChannel); > Changin this to > @LogMessage(level=Logger.Level.DEBUG) > Would ensure that an INFO log event is not seen every time a jms message is sent to the server. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 17:20:49 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 17:20:49 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-108) Incorrect use of ReloadRequiredWriteAttributeHandler for host resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016973#comment-13016973 ] RH Bugzilla Integration commented on WFCORE-108: ------------------------------------------------ Paul Gier changed the Status of [bug 1085228|https://bugzilla.redhat.com/show_bug.cgi?id=1085228] from MODIFIED to ON_QA > Incorrect use of ReloadRequiredWriteAttributeHandler for host resources > ----------------------------------------------------------------------- > > Key: WFCORE-108 > URL: https://issues.jboss.org/browse/WFCORE-108 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Chao Wang > Priority: Critical > Fix For: 1.0.0.Alpha9 > > > ReloadRequiredWriteAttributeHandler inherits the default behavior of AbstractWriteAttributeHandler.requiresRuntime(), which is to only process Stage.RUNTIME if context.isNormalServer(). So any use in host resources needs to override that behavior. This isn't done in at least some places. See https://bugzilla.redhat.com/show_bug.cgi?id=1085228 for an example. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 17:20:49 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 3 Nov 2014 17:20:49 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4045) Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016974#comment-13016974 ] RH Bugzilla Integration commented on WFLY-4045: ----------------------------------------------- Paul Gier changed the Status of [bug 1159814|https://bugzilla.redhat.com/show_bug.cgi?id=1159814] from MODIFIED to ON_QA > Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue > ------------------------------------------------------------------ > > Key: WFLY-4045 > URL: https://issues.jboss.org/browse/WFLY-4045 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > Add a regression test for https://issues.jboss.org/browse/WFCORE-190 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 18:39:35 2014 From: issues at jboss.org (Farah Juma (JIRA)) Date: Mon, 3 Nov 2014 18:39:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3296) JSF NullPointerException with JDK 1.8.0_05 on Windows In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farah Juma resolved WFLY-3296. ------------------------------ Resolution: Out of Date > JSF NullPointerException with JDK 1.8.0_05 on Windows > ----------------------------------------------------- > > Key: WFLY-3296 > URL: https://issues.jboss.org/browse/WFLY-3296 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 8.1.0.CR1 > Environment: Microsoft Windows [Version 6.1.7601] > java version "1.8.0_05" > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > Java HotSpot(TM) Client VM (build 25.5-b02, mixed mode) > Reporter: Dino Tsoumakis > Assignee: Farah Juma > > Running the same web-app on Wildfly 8.1.0.CR1 with > a) JDK 1.7.0_51 > b) JDK 1.8.0_05 > results in no problem on 1.7 JDK, but throws a NullPointerException on JDK 1.8. This might be a JDK bug. > Stack trace on JDK 1.8 is: > 2014-04-27 21:05:52,207 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-15) Error Rendering View[/secure/dashboard.xhtml]: java.lang.NullPointerException > at java.lang.Class.isAssignableFrom(Native Method) [rt.jar:1.8.0_05] > at java.beans.Introspector.isAssignable(Introspector.java:809) [rt.jar:1.8.0_05] > at java.beans.Introspector.processPropertyDescriptors(Introspector.java:705) [rt.jar:1.8.0_05] > at java.beans.Introspector.getTargetPropertyInfo(Introspector.java:553) [rt.jar:1.8.0_05] > at java.beans.Introspector.getBeanInfo(Introspector.java:428) [rt.jar:1.8.0_05] > at java.beans.Introspector.getBeanInfo(Introspector.java:173) [rt.jar:1.8.0_05] > at javax.el.BeanELResolver$BeanProperties.(BeanELResolver.java:223) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final] > at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:726) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final] > at javax.el.BeanELResolver.getValue(BeanELResolver.java:351) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final] > at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.el.parser.AstValue.getValue(AstValue.java:140) [javax.el-3.0.0.jar:] > at com.sun.el.parser.AstValue.getValue(AstValue.java:204) [javax.el-3.0.0.jar:] > at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-3.0.0.jar:] > at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.facelets.component.UIRepeat.getValue(UIRepeat.java:279) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.facelets.component.UIRepeat.getDataModel(UIRepeat.java:255) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.facelets.component.UIRepeat.setIndex(UIRepeat.java:523) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.facelets.component.UIRepeat.process(UIRepeat.java:577) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.facelets.component.UIRepeat.encodeChildren(UIRepeat.java:1110) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:115) [jsf-impl-2.2.6-jbossorg-3.jar:] > at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:889) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:115) [jsf-impl-2.2.6-jbossorg-3.jar:] > at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:889) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1857) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at com.sun.faces.renderkit.html_basic.CompositeRenderer.encodeChildren(CompositeRenderer.java:78) [jsf-impl-2.2.6-jbossorg-3.jar:] > at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:889) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1857) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at javax.faces.render.Renderer.encodeChildren(Renderer.java:176) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:889) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1857) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1860) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1860) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:461) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133) [jsf-impl-2.2.6-jbossorg-3.jar:] > at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.6-jbossorg-3.jar:] > at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.6-jbossorg-3.jar:] > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.6.jar:2.2.6] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at de.diehl.metering.izar.net.application.components.fileupload.FileUploadFilter.doFilter(FileUploadFilter.java:53) [classes:] > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.5.Final.jar:1.0.5.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.5.Final.jar:1.0.5.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 19:16:35 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 19:16:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4036) update EclipseLink/OpenJPA test case to filter out javax.persistence classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016987#comment-13016987 ] Brian Stansberry commented on WFLY-4036: ---------------------------------------- https://github.com/wildfly/wildfly/pull/6903 @Ignores these tests as part of upgrading WildFly Core to the release where they'll start to fail. > update EclipseLink/OpenJPA test case to filter out javax.persistence classes > ---------------------------------------------------------------------------- > > Key: WFLY-4036 > URL: https://issues.jboss.org/browse/WFLY-4036 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 9.0.0.Beta1 > > Attachments: module.xml, module.xml, stacktrace.txt > > > JBoss modules is improving the case when two modules have bi-directional dependencies (a depends on b and b depends on a). Part of this is ensuring that module level classes are used over classes from dependencies (child first). > This jira is about fixing this for two of our unit tests that willl have this problem (an EclipseLink + OpenJPA static module test). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 20:29:35 2014 From: issues at jboss.org (Jeff Zhang (JIRA)) Date: Mon, 3 Nov 2014 20:29:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3881) User shouldn't be able to use empty JNDI name ('java:/' or 'java:jboss/') In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Zhang resolved WFLY-3881. ------------------------------ Fix Version/s: 9.0.0.Beta1 Resolution: Done BZ1019260/BZ1027827 > User shouldn't be able to use empty JNDI name ('java:/' or 'java:jboss/') > ------------------------------------------------------------------------- > > Key: WFLY-3881 > URL: https://issues.jboss.org/browse/WFLY-3881 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 9.0.0.Alpha1 > Reporter: Jeff Zhang > Assignee: Jeff Zhang > Priority: Minor > Fix For: 9.0.0.Beta1 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1019260 > Description of problem: > Currently the only validation for JNDI names is: JNDI name has to start with 'java:/' or 'java:jboss/'. But user is able to enter just 'java:/' or 'java:jboss/' as JNDI name. Using this JNDI name for eg. data-source will lead to java.lang.IllegalArgumentException: Empty name segment is not allowed for jboss. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:14:35 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Mon, 3 Nov 2014 21:14:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4048) Make sure predicated handlers (like handle-info.conf) can be used at a server level In-Reply-To: References: Message-ID: Stuart Douglas created WFLY-4048: ------------------------------------ Summary: Make sure predicated handlers (like handle-info.conf) can be used at a server level Key: WFLY-4048 URL: https://issues.jboss.org/browse/WFLY-4048 Project: WildFly Issue Type: Feature Request Components: Web (Undertow) Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:44 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-213: ------------------------------------ Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha12, 1.0.0.Beta1 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:45 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-207) write- and undefine-attribute operations are registered as runtime-only In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-207: ------------------------------------ Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > write- and undefine-attribute operations are registered as runtime-only > ----------------------------------------------------------------------- > > Key: WFCORE-207 > URL: https://issues.jboss.org/browse/WFCORE-207 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 1.0.0.Alpha12 > > > The write-attribute and undefine-attribute operation are registered as runtime-only, which is not correct and was probably done unintentionally. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:45 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-165) Server jvm settings take effect only after host controller restart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-165: ------------------------------------ Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Server jvm settings take effect only after host controller restart > ------------------------------------------------------------------- > > Key: WFCORE-165 > URL: https://issues.jboss.org/browse/WFCORE-165 > Project: WildFly Core > Issue Type: Feature Request > Affects Versions: 1.0.0.Alpha9 > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 1.0.0.Alpha12 > > > If you start a domain/host with one server, and that server has e.g. a too small heap: > {code} > > > > > > > > > {code} > The server will fail on boot: > {code} > [Server:server-one] Error occurred during initialization of VM > [Server:server-one] Too small initial heap > {code} > Trying to call > {code} > /host=master/server-config=server-one/jvm=default:write-attribute(name=heap-size,value=64m) > /host=master/server-config=server-one:start > {code} > results in the same error. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:45 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-137) Add Kerberos tests to domain-management module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-137: ------------------------------------ Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Add Kerberos tests to domain-management module > ---------------------------------------------- > > Key: WFCORE-137 > URL: https://issues.jboss.org/browse/WFCORE-137 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha12 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:46 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-133) CLI -connect option throws full stacktrace exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-133: ------------------------------------ Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > CLI -connect option throws full stacktrace exception > ---------------------------------------------------- > > Key: WFCORE-133 > URL: https://issues.jboss.org/browse/WFCORE-133 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha8 > Reporter: Joe Wertz > Assignee: Joe Wertz > Priority: Minor > Fix For: 1.0.0.Alpha12 > > > Full stacktrace is printed for exceptions that occur before the CLI connects to a server. > Instead, only the exception messages should be printed. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:46 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-129) Overlay does not work for subunits in exploded deployments. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-129: ------------------------------------ Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Overlay does not work for subunits in exploded deployments. > ----------------------------------------------------------- > > Key: WFCORE-129 > URL: https://issues.jboss.org/browse/WFCORE-129 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha8 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Alpha12 > > > If deployment is exploded and has subdeployments overlay wont work on files contained in said subdeployments. > Reproducers: https://github.com/baranowb/wildfly/tree/WFCORE-83-TESTS -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:47 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:47 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-107: ------------------------------------ Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Update whoami operation to return authentication mechanism where verbose=true > ----------------------------------------------------------------------------- > > Key: WFCORE-107 > URL: https://issues.jboss.org/browse/WFCORE-107 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha12 > > > The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached. > This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:47 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:47 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-106) Enable GSSAPI/Kerberos Support for domain management over Remoting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-106: ------------------------------------ Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Enable GSSAPI/Kerberos Support for domain management over Remoting > ------------------------------------------------------------------ > > Key: WFCORE-106 > URL: https://issues.jboss.org/browse/WFCORE-106 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha12 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:47 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:47 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-104) Add GSSAPI support to CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-104: ------------------------------------ Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Add GSSAPI support to CLI > ------------------------- > > Key: WFCORE-104 > URL: https://issues.jboss.org/browse/WFCORE-104 > Project: WildFly Core > Issue Type: Sub-task > Components: CLI, Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Kerberos, management_security, > Fix For: 1.0.0.Alpha12 > > > Once the Native interface supports GSSAPI then the CLI will also need to support this. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:48 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:48 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-103) Add Full Kerberos Support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-103: ------------------------------------ Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Add Full Kerberos Support > ------------------------- > > Key: WFCORE-103 > URL: https://issues.jboss.org/browse/WFCORE-103 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: management_security, > Fix For: 1.0.0.Alpha12 > > > There are a number of steps required to full add Kerberos support - this is a top level tracking task to be resolved once all steps are complete. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:49 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:49 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-94) Add -secmgr to startup scripts and propagate -secmgr through the domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-94: ----------------------------------- Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Add -secmgr to startup scripts and propagate -secmgr through the domain > ----------------------------------------------------------------------- > > Key: WFCORE-94 > URL: https://issues.jboss.org/browse/WFCORE-94 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Scripts > Reporter: Kabir Khan > Assignee: James Perkins > Fix For: 1.0.0.Alpha12 > > > The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain. > The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:49 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:49 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-80) Upgrade org.apache.httpcomponents:httpclient to 4.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-80: ----------------------------------- Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Upgrade org.apache.httpcomponents:httpclient to 4.3.2 > ----------------------------------------------------- > > Key: WFCORE-80 > URL: https://issues.jboss.org/browse/WFCORE-80 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Affects Versions: 1.0.0.Alpha5 > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 1.0.0.Alpha12 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:49 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:49 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-77) We need even better reporting for failed authentications In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-77: ----------------------------------- Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > We need even better reporting for failed authentications > -------------------------------------------------------- > > Key: WFCORE-77 > URL: https://issues.jboss.org/browse/WFCORE-77 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha12 > > > The following message is often the one reported to users: - > {noformat} > >> Caused by: javax.security.sasl.SaslException: Authentication failed: > >> the server presented no authentication mechanisms > {noformat} > Whilst technically it is true at that point in time this is most likely caused because other mechanisms have already been tried and failed and the list of mechanisms to try is now exhausted. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:50 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:50 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-54) Add Keycloak authentication/authorization to http management endpoint In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-54: ----------------------------------- Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Add Keycloak authentication/authorization to http management endpoint > --------------------------------------------------------------------- > > Key: WFCORE-54 > URL: https://issues.jboss.org/browse/WFCORE-54 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Stan Silvert > Assignee: Stan Silvert > Fix For: 1.0.0.Alpha12 > > > This is here to track the core changes needed for WFLY-3591. See that jira for details. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:50 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:50 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-42) Add a ServerXml Parser which extends CommonXml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-42: ----------------------------------- Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Add a ServerXml Parser which extends CommonXml > ---------------------------------------------- > > Key: WFCORE-42 > URL: https://issues.jboss.org/browse/WFCORE-42 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha12 > > > Both StandaloneXml and AppclientXml parse XML starting from the server element. > This duplication has always been problematic as AppclientXml is completely separate from the remaining domain config parsing, however with the core split this is even worse. > This change is to introduce a ServerXml that can be the common base for both StandaloneXml and AppclientXml - except in extreme cases it will then be safe to ignore AppclientXml for further schema updates. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:51 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:51 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-31) The JBoss Modules schemas are missing from the build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-31: ----------------------------------- Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > The JBoss Modules schemas are missing from the build > ---------------------------------------------------- > > Key: WFCORE-31 > URL: https://issues.jboss.org/browse/WFCORE-31 > Project: WildFly Core > Issue Type: Bug > Reporter: Darran Lofthouse > Assignee: Eduardo Martins > Fix For: 1.0.0.Alpha12 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:15:52 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 3 Nov 2014 21:15:52 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-25) Windows PowerShell scripts in bin In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-25: ----------------------------------- Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha11) > Windows PowerShell scripts in bin > --------------------------------- > > Key: WFCORE-25 > URL: https://issues.jboss.org/browse/WFCORE-25 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha12 > > > Add .psh scripts that match the functionality of our .sh scripts. Leave the .bat scripts in their current limited-functionality form for people still on XP, but use PowerShell as the recommended Windows scripting language. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:25:44 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Mon, 3 Nov 2014 21:25:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4020) CVE-2014-7816 Information disclosure via directory traversal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas resolved WFLY-4020. ---------------------------------- Fix Version/s: 8.2.0.CR1 9.0.0.Beta1 Resolution: Done > CVE-2014-7816 Information disclosure via directory traversal > ------------------------------------------------------------ > > Key: WFLY-4020 > URL: https://issues.jboss.org/browse/WFLY-4020 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Arun Neelicattu > Assignee: Stuart Douglas > Labels: CVE-2014-7816, component:undertow > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > Directory traversal vulnerability allows access to arbitrary files. This can be triggered by using `dot dot` prefix to requested resource URI. > Refer to [CVE-2014-7816|https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-7816] for more information. > Undertow issue is at UNDERTOW-338. > Note that at the time of filing this is under embargo until instructed by the original reporter. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:38:35 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Mon, 3 Nov 2014 21:38:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4048) Make sure predicated handlers (like handler-info.conf) can be used at a server level In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas updated WFLY-4048: --------------------------------- Summary: Make sure predicated handlers (like handler-info.conf) can be used at a server level (was: Make sure predicated handlers (like handle-info.conf) can be used at a server level) > Make sure predicated handlers (like handler-info.conf) can be used at a server level > ------------------------------------------------------------------------------------ > > Key: WFLY-4048 > URL: https://issues.jboss.org/browse/WFLY-4048 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 21:40:35 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Mon, 3 Nov 2014 21:40:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3969) HeaderTokenParser doesn't parse correctly values which includes a quote In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas resolved WFLY-3969. ---------------------------------- Fix Version/s: 8.2.0.CR1 9.0.0.Beta1 Resolution: Done > HeaderTokenParser doesn't parse correctly values which includes a quote > ----------------------------------------------------------------------- > > Key: WFLY-3969 > URL: https://issues.jboss.org/browse/WFLY-3969 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > Priority: Critical > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > The header parser doesn't work correctly if a parsed value contains quote character ("). The problem is, the parser is in phase of searching a LAST_QUOTE and it doesn't check if the found quote character is escaped or not. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 22:40:36 2014 From: issues at jboss.org (Boleslav Bobcik (JIRA)) Date: Mon, 3 Nov 2014 22:40:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBASMP-74) Allow custom connection timeout specification In-Reply-To: References: Message-ID: Boleslav Bobcik created JBASMP-74: ------------------------------------- Summary: Allow custom connection timeout specification Key: JBASMP-74 URL: https://issues.jboss.org/browse/JBASMP-74 Project: JBoss AS Maven Plugins Issue Type: Feature Request Affects Versions: 7.6.Final Reporter: Boleslav Bobcik Assignee: James Perkins In certain environments (such as JBoss AS running in VirtualBox under NAT) the default connection timeout (defined as 5000ms in org.jboss.as.controller.client.impl.ClientConfigurationImpl) is insufficient - the initial remoting handshake may need up to 30 seconds. Controller client module can apply a timeout, however it has to be provided as an argument to a factory method of ModelControllerClient; I didn't find any means of implicit configuration via system property, environment variable etc. Therefore the proposal is to add a property to AbstractServerConnection that would allow custom specification of connection timeout. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Nov 3 22:43:35 2014 From: issues at jboss.org (Boleslav Bobcik (JIRA)) Date: Mon, 3 Nov 2014 22:43:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBASMP-74) Allow custom connection timeout specification In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBASMP-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boleslav Bobcik updated JBASMP-74: ---------------------------------- Attachment: connectTimeout.patch Prototype patch of implemented timeout property > Allow custom connection timeout specification > --------------------------------------------- > > Key: JBASMP-74 > URL: https://issues.jboss.org/browse/JBASMP-74 > Project: JBoss AS Maven Plugins > Issue Type: Feature Request > Affects Versions: 7.6.Final > Reporter: Boleslav Bobcik > Assignee: James Perkins > Attachments: connectTimeout.patch > > > In certain environments (such as JBoss AS running in VirtualBox under NAT) the default connection timeout (defined as 5000ms in org.jboss.as.controller.client.impl.ClientConfigurationImpl) is insufficient - the initial remoting handshake may need up to 30 seconds. > Controller client module can apply a timeout, however it has to be provided as an argument to a factory method of ModelControllerClient; I didn't find any means of implicit configuration via system property, environment variable etc. > Therefore the proposal is to add a property to AbstractServerConnection that would allow custom specification of connection timeout. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 02:16:35 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Tue, 4 Nov 2014 02:16:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-215) Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek moved WFLY-4045 to WFCORE-215: ------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-215 (was: WFLY-4045) Component/s: Test Suite (was: Test Suite) > Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue > ------------------------------------------------------------------ > > Key: WFCORE-215 > URL: https://issues.jboss.org/browse/WFCORE-215 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > Add a regression test for https://issues.jboss.org/browse/WFCORE-190 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 02:21:35 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Tue, 4 Nov 2014 02:21:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-215) Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek updated WFCORE-215: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/285 (was: https://github.com/wildfly/wildfly/pull/6900) > Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue > ------------------------------------------------------------------ > > Key: WFCORE-215 > URL: https://issues.jboss.org/browse/WFCORE-215 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > Add a regression test for https://issues.jboss.org/browse/WFCORE-190 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 02:25:35 2014 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 4 Nov 2014 02:25:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-212) java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Remes updated WFCORE-212: ------------------------------- Affects Version/s: 1.0.0.Alpha11 > java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-212 > URL: https://issues.jboss.org/browse/WFCORE-212 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11 > Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20 > Reporter: Tomas Remes > Assignee: Jason Greene > Attachments: test-jms.zip > > > Following steps to reproduce section you will encounter this exception: > {noformat} > 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0 > at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20] > at org.jboss.as.controller.PathElement.(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184) > at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20] > {noformat} > Note that the attached WAR works fine when the following is removed from ejb-jar.xml: > {noformat} > > subscriptionDurability > Durable > > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 03:02:35 2014 From: issues at jboss.org (Tomas Remes (JIRA)) Date: Tue, 4 Nov 2014 03:02:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-212) java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017012#comment-13017012 ] Tomas Remes commented on WFCORE-212: ------------------------------------ Looks like client identifier is missing {noformat} clientId test {noformat} However looking at EJB spec "5.4.17.8 Client Identifier" this configuration is not required. > java.lang.StringIndexOutOfBoundsException during deployment of war with specific ejb jar descriptor > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-212 > URL: https://issues.jboss.org/browse/WFCORE-212 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha9, 1.0.0.Alpha11 > Environment: WildFly-9.0.0.Alpha2-SNAPSHOT 2014-11-03, oracle-jdk 1.8.0_20 > Reporter: Tomas Remes > Assignee: Jason Greene > Attachments: test-jms.zip > > > Following steps to reproduce section you will encounter this exception: > {noformat} > 15:25:04,304 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: java.lang.StringIndexOutOfBoundsException: String index out of range: 0 > at java.lang.String.charAt(String.java:646) [rt.jar:1.8.0_20] > at org.jboss.as.controller.PathElement.(PathElement.java:102) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.PathElement.pathElement(PathElement.java:67) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.PlaceholderResource$PlaceholderResourceEntry.(PlaceholderResource.java:141) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.messaging.HornetQServerResource.getChildren(HornetQServerResource.java:184) > at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:280) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:640) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:381) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:577) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:803) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:778) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:535) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:308) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:303) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1158) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:404) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.server.ServerService.boot(ServerService.java:364) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.server.ServerService.boot(ServerService.java:339) [wildfly-server-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [wildfly-controller-1.0.0.Alpha9.jar:1.0.0.Alpha9] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20] > {noformat} > Note that the attached WAR works fine when the following is removed from ejb-jar.xml: > {noformat} > > subscriptionDurability > Durable > > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 03:21:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Nov 2014 03:21:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3625) Inconsistent deployment status when deploy an EJB containing wrong dependencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017016#comment-13017016 ] RH Bugzilla Integration commented on WFLY-3625: ----------------------------------------------- Chao Wang changed the Status of [bug 1119159|https://bugzilla.redhat.com/show_bug.cgi?id=1119159] from NEW to CLOSED > Inconsistent deployment status when deploy an EJB containing wrong dependencies > ------------------------------------------------------------------------------- > > Key: WFLY-3625 > URL: https://issues.jboss.org/browse/WFLY-3625 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 8.1.0.Final > Reporter: Lyle Wang > Assignee: Jason Greene > Attachments: WFLY-3625.zip > > > On deploying an EJB (in exploded ear) which has wrong @Resource/"lookup" JNDI names, it gives ERROR log. The marker file is changed to "***.ear.failed", but in web console "http://localhost:9990" the deployment is displayed in "Manage Deployments" page and shows deployed. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 03:34:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Nov 2014 03:34:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-516) 6.1.0.beta4 and identified a rule pattern inducing memory leaks In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated DROOLS-516: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1160162 > 6.1.0.beta4 and identified a rule pattern inducing memory leaks > --------------------------------------------------------------- > > Key: DROOLS-516 > URL: https://issues.jboss.org/browse/DROOLS-516 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Beta3, 6.1.0.Beta4 > Reporter: Matteo Mortari > Assignee: Mario Fusco > Labels: backport-to-6.0.x > Fix For: 6.1.0.Final > > Attachments: 20140604.anotherleak.zip, 20140604.anotherleak_erratacorrige.zip, Java_VisualVM_2014-06-05_11-38-12.png, Java_VisualVM_2014-06-05_11-43-06.png > > > Ciao I'm using 6.1.0.beta4 and I identified in my application a rule pattern inducing memory leaks. I will attach rule, screenshots, and javacode to replicate the issue. > Steps to replicate identification of issue: > * IF the rule {{After No data received within the last 1 hour Error, now resumed}} is included, memory leaks happens, and pretty quickly. > * IF such rule is commented out, application do manage to keep alive. > Same problem happens even on 6.1.0.beta3 - I did not test with previous versions. > Thanks a lot in advance, > Ciao > Matteo -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 03:40:35 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 4 Nov 2014 03:40:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4046) Container lifecycle event method invoked outside of extension observer method invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017020#comment-13017020 ] Jozef Hartinger commented on WFLY-4046: --------------------------------------- My suggestion would be to: {quote} CamelExtension can get around this by storing AnnotatedTypes, not ProcessAnnotatedType events here: https://github.com/tdiesler/camel/blob/trunk/components/camel-cdi/src/main/java/org/apache/camel/cdi/internal/CamelContextConfig.java#L39 {quote} > Container lifecycle event method invoked outside of extension observer method invocation > ---------------------------------------------------------------------------------------- > > Key: WFLY-4046 > URL: https://issues.jboss.org/browse/WFLY-4046 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Thomas Diesler > Assignee: Jozef Hartinger > > Cannot deploy war that uses camel-cdi > This works in 8.1.0.Final > {code} > org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. > at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) > at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) > at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) > at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) > at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) > {code} > Cross Issue: https://issues.apache.org/jira/browse/CAMEL-7992 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 03:41:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Nov 2014 03:41:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3939) jndiView operation from JConsole returns void In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017021#comment-13017021 ] RH Bugzilla Integration commented on WFLY-3939: ----------------------------------------------- Petr Kremensky changed the Status of [bug 1149987|https://bugzilla.redhat.com/show_bug.cgi?id=1149987] from ON_QA to VERIFIED > jndiView operation from JConsole returns void > --------------------------------------------- > > Key: WFLY-3939 > URL: https://issues.jboss.org/browse/WFLY-3939 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.1.0.Final > Reporter: Osamu Nagano > Assignee: Eduardo Martins > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > When I press "jndiView" operation button (navigate jboss.as / naming / Operations in MBeans tab of JConsole), an info dialog box returns with message "Method successfully invoked". The contents of JNDI view is not printed anywhere. It should return that as String or dump the contents into stdout. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 03:46:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Nov 2014 03:46:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-166) LDAP caching for security realm not caching where a user does not exist on the server. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017024#comment-13017024 ] RH Bugzilla Integration commented on WFCORE-166: ------------------------------------------------ Josef Cacek changed the Status of [bug 1150608|https://bugzilla.redhat.com/show_bug.cgi?id=1150608] from ON_QA to VERIFIED > LDAP caching for security realm not caching where a user does not exist on the server. > -------------------------------------------------------------------------------------- > > Key: WFCORE-166 > URL: https://issues.jboss.org/browse/WFCORE-166 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha10 > > > Where the caches are configured within the security realms to cache failures missing users are not cached. > This is due to an IOException being used to report the missing user instead of a NamingException - we deliberately do not cache an IOException as that could also be as a result of the server being temporarily unavailable, -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 04:44:35 2014 From: issues at jboss.org (Ladislav Thon (JIRA)) Date: Tue, 4 Nov 2014 04:44:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1888) FD_SOCK race condition during stop In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017041#comment-13017041 ] Ladislav Thon commented on JGRP-1888: ------------------------------------- Just noting that the reproducer requires using Java 7, because it uses {{InetAddress.getLoopbackAddress()}}. Changing that to {{InetAddress.getLocalHost()}} seems to be fine (the test fails when unpatched and passes when patched). > FD_SOCK race condition during stop > ---------------------------------- > > Key: JGRP-1888 > URL: https://issues.jboss.org/browse/JGRP-1888 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.6.16 > Reporter: Dennis Reed > Assignee: Dennis Reed > Fix For: 2.6.23 > > Attachments: jgrp-1888-test.tar.gz > > > There is a race condition in FD_SOCK between stop() shutting down the pinger thread and the BroadcastTask. > It first shuts down the broadcast task, and then the pinger thread. > If the pinger thread generates a new suspected event in this interval, it re-starts the broadcast task, which creates a new thread suspecting that node repeatedly until the JVM exits. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 05:37:35 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 4 Nov 2014 05:37:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4049) EJBClientXidTransactionTestCase fails due to ARJUNA022006: The ORB has not been initialized yet In-Reply-To: References: Message-ID: Tom Jenkinson created WFLY-4049: ----------------------------------- Summary: EJBClientXidTransactionTestCase fails due to ARJUNA022006: The ORB has not been initialized yet Key: WFLY-4049 URL: https://issues.jboss.org/browse/WFLY-4049 Project: WildFly Issue Type: Feature Request Components: Test Suite Reporter: Tom Jenkinson Assignee: Tom Jenkinson Description of problem: org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase - testSLSBMandatoryTx - testClientTransactionManagement fails once run with other tests with ARJUNA022006: The ORB has not been initialized yet How reproducible: Not if run as a single test, only once I run whole it.basic module Steps to Reproduce: 1. See reproducer jobs configuration Actual results: org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testSLSBMandatoryTx testReport/org.jboss.as.test.integration.ejb.remote.client.api.tx/EJBClientXidTransactionTestCase/testSLSBMandatoryTx/ com.arjuna.ats.arjuna.exceptions.FatalError at com.arjuna.ats.internal.jts.ORBManager.getPOA(ORBManager.java:96) at com.arjuna.ats.internal.jts.OTSImpleManager.(OTSImpleManager.java:296) at java.lang.J9VMInternals.initializeImpl(Native Method) at java.lang.J9VMInternals.initialize(J9VMInternals.java:201) at com.arjuna.ats.jts.OTSManager.get_current(OTSManager.java:71) at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.checkTransactionState(BaseTransaction.java:265) at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.begin(BaseTransaction.java:72) at org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testSLSBMandatoryTx(EJBClientXidTransactionTestCase.java:130) org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testClientTransactionManagement testReport/org.jboss.as.test.integration.ejb.remote.client.api.tx/EJBClientXidTransactionTestCase/testClientTransactionManagement/ java.lang.NoClassDefFoundError: com.arjuna.ats.internal.jts.OTSImpleManager (initialization failure) at java.lang.J9VMInternals.initialize(J9VMInternals.java:141) at com.arjuna.ats.jts.OTSManager.get_current(OTSManager.java:71) at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.checkTransactionState(BaseTransaction.java:265) at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.begin(BaseTransaction.java:72) at org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase.testClientTransactionManagement(EJBClientXidTransactionTestCase.java:152) Expected results: Both tests pass -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 05:41:35 2014 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Tue, 4 Nov 2014 05:41:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-165) Server jvm settings take effect only after host controller restart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFCORE-165: ------------------------------ Fix Version/s: 1.0.0.Alpha11 (was: 1.0.0.Alpha12) > Server jvm settings take effect only after host controller restart > ------------------------------------------------------------------- > > Key: WFCORE-165 > URL: https://issues.jboss.org/browse/WFCORE-165 > Project: WildFly Core > Issue Type: Feature Request > Affects Versions: 1.0.0.Alpha9 > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 1.0.0.Alpha11 > > > If you start a domain/host with one server, and that server has e.g. a too small heap: > {code} > > > > > > > > > {code} > The server will fail on boot: > {code} > [Server:server-one] Error occurred during initialization of VM > [Server:server-one] Too small initial heap > {code} > Trying to call > {code} > /host=master/server-config=server-one/jvm=default:write-attribute(name=heap-size,value=64m) > /host=master/server-config=server-one:start > {code} > results in the same error. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 05:42:35 2014 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Tue, 4 Nov 2014 05:42:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-165) Server jvm settings take effect only after host controller restart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan resolved WFCORE-165. ------------------------------- Resolution: Done > Server jvm settings take effect only after host controller restart > ------------------------------------------------------------------- > > Key: WFCORE-165 > URL: https://issues.jboss.org/browse/WFCORE-165 > Project: WildFly Core > Issue Type: Feature Request > Affects Versions: 1.0.0.Alpha9 > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 1.0.0.Alpha11 > > > If you start a domain/host with one server, and that server has e.g. a too small heap: > {code} > > > > > > > > > {code} > The server will fail on boot: > {code} > [Server:server-one] Error occurred during initialization of VM > [Server:server-one] Too small initial heap > {code} > Trying to call > {code} > /host=master/server-config=server-one/jvm=default:write-attribute(name=heap-size,value=64m) > /host=master/server-config=server-one:start > {code} > results in the same error. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 06:04:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Nov 2014 06:04:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-161) JMX monitoring is extremely memory inefficient In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017072#comment-13017072 ] RH Bugzilla Integration commented on WFCORE-161: ------------------------------------------------ Jan Martiska changed the Status of [bug 1150304|https://bugzilla.redhat.com/show_bug.cgi?id=1150304] from ON_QA to VERIFIED > JMX monitoring is extremely memory inefficient > ---------------------------------------------- > > Key: WFCORE-161 > URL: https://issues.jboss.org/browse/WFCORE-161 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Koen Janssens > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha11 > > > When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created. > A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class. > More background on associated forum thread -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 06:43:37 2014 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Tue, 4 Nov 2014 06:43:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-216) looks requires are completely ignore in AttributeDefinition when attribute is validated In-Reply-To: References: Message-ID: Stefano Maestri created WFCORE-216: -------------------------------------- Summary: looks requires are completely ignore in AttributeDefinition when attribute is validated Key: WFCORE-216 URL: https://issues.jboss.org/browse/WFCORE-216 Project: WildFly Core Issue Type: Bug Reporter: Stefano Maestri Assignee: Tomaz Cerar -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 06:45:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Nov 2014 06:45:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-216) looks requires are completely ignore in AttributeDefinition when attribute is validated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-216: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1023064 > looks requires are completely ignore in AttributeDefinition when attribute is validated > --------------------------------------------------------------------------------------- > > Key: WFCORE-216 > URL: https://issues.jboss.org/browse/WFCORE-216 > Project: WildFly Core > Issue Type: Bug > Reporter: Stefano Maestri > Assignee: Tomaz Cerar > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 07:00:38 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 4 Nov 2014 07:00:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-216) looks requires are completely ignore in AttributeDefinition when attribute is validated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFCORE-216: ------------------------------- Component/s: Domain Management > looks requires are completely ignore in AttributeDefinition when attribute is validated > --------------------------------------------------------------------------------------- > > Key: WFCORE-216 > URL: https://issues.jboss.org/browse/WFCORE-216 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stefano Maestri > Assignee: Tomaz Cerar > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 07:00:38 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 4 Nov 2014 07:00:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-216) requires are completely ignore in AttributeDefinition when attribute is validated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFCORE-216: ------------------------------- Summary: requires are completely ignore in AttributeDefinition when attribute is validated (was: looks requires are completely ignore in AttributeDefinition when attribute is validated) > requires are completely ignore in AttributeDefinition when attribute is validated > --------------------------------------------------------------------------------- > > Key: WFCORE-216 > URL: https://issues.jboss.org/browse/WFCORE-216 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stefano Maestri > Assignee: Tomaz Cerar > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 08:53:36 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Tue, 4 Nov 2014 08:53:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4050) data-source:enable broken In-Reply-To: References: Message-ID: Harald Pehl created WFLY-4050: --------------------------------- Summary: data-source:enable broken Key: WFLY-4050 URL: https://issues.jboss.org/browse/WFLY-4050 Project: WildFly Issue Type: Bug Components: JCA Affects Versions: 9.0.0.Alpha1, 8.1.0.Final, 8.0.0.Final Reporter: Harald Pehl Assignee: Jesper Pedersen Enabling a datasource using the operation {{:enable()}} is broken. It remains disabled. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 08:54:36 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Tue, 4 Nov 2014 08:54:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4050) data-source:enable is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4050: ------------------------------ Summary: data-source:enable is broken (was: data-source:enable broken) > data-source:enable is broken > ---------------------------- > > Key: WFLY-4050 > URL: https://issues.jboss.org/browse/WFLY-4050 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Final, 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Harald Pehl > Assignee: Jesper Pedersen > > Enabling a datasource using the operation {{:enable()}} is broken. It remains disabled. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 08:55:36 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Tue, 4 Nov 2014 08:55:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4050) data-source:enable is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4050: ------------------------------ Assignee: Stefano Maestri (was: Jesper Pedersen) > data-source:enable is broken > ---------------------------- > > Key: WFLY-4050 > URL: https://issues.jboss.org/browse/WFLY-4050 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Final, 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Harald Pehl > Assignee: Stefano Maestri > > Enabling a datasource using the operation {{:enable()}} is broken. It remains disabled. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 08:55:37 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Tue, 4 Nov 2014 08:55:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4050) data-source:enable is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4050: ------------------------------ Description: Enabling a disabled datasource using the operation {{:enable()}} is broken. It remains disabled. (was: Enabling a datasource using the operation {{:enable()}} is broken. It remains disabled. ) > data-source:enable is broken > ---------------------------- > > Key: WFLY-4050 > URL: https://issues.jboss.org/browse/WFLY-4050 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Final, 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Harald Pehl > Assignee: Stefano Maestri > > Enabling a disabled datasource using the operation {{:enable()}} is broken. It remains disabled. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 08:56:35 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Tue, 4 Nov 2014 08:56:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4050) data-source:enable is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4050: ------------------------------ Steps to Reproduce: In domain mode # {{/profile=full/subsystem=datasources/data-source=foo:add(jndi-name=java:jboss/datasources/foo,driver-name=h2,connection-url=jdbc:h2:mem:foo,enabled=false)}} # {{/profile=full/subsystem=datasources/data-source=foo:enable()\{allow-resource-service-restart=true\}}} # {{/profile=full/subsystem=datasources/data-source=foo:read-attribute(name=enabled)}} returns false # {{reload --host=master --restart-servers=true}} # {{/profile=full/subsystem=datasources/data-source=foo:read-attribute(name=enabled)}} still returns false was: # {{/profile=full/subsystem=datasources/data-source=foo:add(jndi-name=java:jboss/datasources/foo,driver-name=h2,connection-url=jdbc:h2:mem:foo,enabled=false)}} # {{/profile=full/subsystem=datasources/data-source=foo:enable()\{allow-resource-service-restart=true\}}} # {{/profile=full/subsystem=datasources/data-source=foo:read-attribute(name=enabled)}} returns false # {{reload --host=master --restart-servers=true}} # {{/profile=full/subsystem=datasources/data-source=foo:read-attribute(name=enabled)}} still returns false > data-source:enable is broken > ---------------------------- > > Key: WFLY-4050 > URL: https://issues.jboss.org/browse/WFLY-4050 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Final, 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Harald Pehl > Assignee: Stefano Maestri > > Enabling a disabled datasource using the operation {{:enable()}} is broken. It remains disabled. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 10:36:07 2014 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Tue, 4 Nov 2014 10:36:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3937) Jackson libs are Private, should be Public In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan reopened WFLY-3937: ------------------------------ > Jackson libs are Private, should be Public > ------------------------------------------ > > Key: WFLY-3937 > URL: https://issues.jboss.org/browse/WFLY-3937 > Project: WildFly > Issue Type: Bug > Environment: EAP 6.3.0.ER2 > Reporter: Marek Novotny > Assignee: Marek Novotny > Fix For: 9.0.0.Beta1 > > > The following libraries have their module.xml files set to *private*: > * org.codehaus.jackson.jackson-core-asl > * org.codehaus.jackson.jackson-mapper-asl > * org.codehaus.jackson.jackson-jaxrs > * org.codehaus.jackson.jackson-xc > After talking with [~bill.burke], these should be *public*. > While these modules are private, the use of them creates WARNings in the stack trace. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 10:36:08 2014 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Tue, 4 Nov 2014 10:36:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3937) Jackson libs are Private, should be Public In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan resolved WFLY-3937. ------------------------------ Resolution: Rejected > Jackson libs are Private, should be Public > ------------------------------------------ > > Key: WFLY-3937 > URL: https://issues.jboss.org/browse/WFLY-3937 > Project: WildFly > Issue Type: Bug > Environment: EAP 6.3.0.ER2 > Reporter: Marek Novotny > Assignee: Marek Novotny > Fix For: 9.0.0.Beta1 > > > The following libraries have their module.xml files set to *private*: > * org.codehaus.jackson.jackson-core-asl > * org.codehaus.jackson.jackson-mapper-asl > * org.codehaus.jackson.jackson-jaxrs > * org.codehaus.jackson.jackson-xc > After talking with [~bill.burke], these should be *public*. > While these modules are private, the use of them creates WARNings in the stack trace. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 10:36:08 2014 From: issues at jboss.org (Kabir Khan (JIRA)) Date: Tue, 4 Nov 2014 10:36:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3937) Jackson libs are Private, should be Public In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kabir Khan updated WFLY-3937: ----------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/6785, https://github.com/wildfly/wildfly/pull/6909 (was: https://github.com/wildfly/wildfly/pull/6785) > Jackson libs are Private, should be Public > ------------------------------------------ > > Key: WFLY-3937 > URL: https://issues.jboss.org/browse/WFLY-3937 > Project: WildFly > Issue Type: Bug > Environment: EAP 6.3.0.ER2 > Reporter: Marek Novotny > Assignee: Marek Novotny > Fix For: 9.0.0.Beta1 > > > The following libraries have their module.xml files set to *private*: > * org.codehaus.jackson.jackson-core-asl > * org.codehaus.jackson.jackson-mapper-asl > * org.codehaus.jackson.jackson-jaxrs > * org.codehaus.jackson.jackson-xc > After talking with [~bill.burke], these should be *public*. > While these modules are private, the use of them creates WARNings in the stack trace. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 10:42:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Nov 2014 10:42:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3937) Jackson libs are Private, should be Public In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017221#comment-13017221 ] RH Bugzilla Integration commented on WFLY-3937: ----------------------------------------------- Kabir Khan changed the Status of [bug 1094937|https://bugzilla.redhat.com/show_bug.cgi?id=1094937] from ON_QA to POST > Jackson libs are Private, should be Public > ------------------------------------------ > > Key: WFLY-3937 > URL: https://issues.jboss.org/browse/WFLY-3937 > Project: WildFly > Issue Type: Bug > Environment: EAP 6.3.0.ER2 > Reporter: Marek Novotny > Assignee: Marek Novotny > Fix For: 9.0.0.Beta1 > > > The following libraries have their module.xml files set to *private*: > * org.codehaus.jackson.jackson-core-asl > * org.codehaus.jackson.jackson-mapper-asl > * org.codehaus.jackson.jackson-jaxrs > * org.codehaus.jackson.jackson-xc > After talking with [~bill.burke], these should be *public*. > While these modules are private, the use of them creates WARNings in the stack trace. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 11:09:35 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Tue, 4 Nov 2014 11:09:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3830) Use external-context for remote TIBCO ems lookup In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017228#comment-13017228 ] Jeff Mesnil commented on WFLY-3830: ----------------------------------- The fix that has been merged on master branch uses the org.jboss.as.naming.lookup.by.string env property to ensure that the JNDI resources will be looked up using the lookup(String) method: > Use external-context for remote TIBCO ems lookup > ------------------------------------------------ > > Key: WFLY-3830 > URL: https://issues.jboss.org/browse/WFLY-3830 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.1.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > If an users uses the generic JMS RA with the TIBCO EMS messaging server, he has to duplicate all the JNDI parameters in the MDB annotations. > Instead, he should be able to use a naming's external-context to connect to the Remote TIBCO server with the following configuration: > {noformat} > > > > > > > > > > {noformat} > With these settings, the user only needs to pass the expected connection factory and destination lookup in the MDB: > {noformat} > @ActivationConfigProperty(propertyName = "connectionFactory", propertyValue = "java:global/tibco/XACF"), > @ActivationConfigProperty(propertyName = "destination", propertyValue = "java:global/tibco/Q1"), > {noformat} > The local JNDI lookup "java:global/tibco/Q1" will then use the external context (bound to "java:global/tibco") to lookup the "Q1" name on the TIBCO EMS. > There are a few bugs in the ExternalObjectFactory that prevents to use this configuration with a regular javax.naming.InitialContext to build the external context. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 11:10:35 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Tue, 4 Nov 2014 11:10:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4051) Use descriptive error message for duplicate host/context deployments In-Reply-To: References: Message-ID: Paul Ferraro created WFLY-4051: ---------------------------------- Summary: Use descriptive error message for duplicate host/context deployments Key: WFLY-4051 URL: https://issues.jboss.org/browse/WFLY-4051 Project: WildFly Issue Type: Enhancement Components: Web (Undertow) Affects Versions: 9.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Stuart Douglas Priority: Minor If a user attempts to deploy a web application to a host/context to which another application is deployed, this will fail for obvious reasons. What isn't obvious is the error message. Currently, users will see a DuplicateServiceException. Ideally, the error message should indicate that another application is deployed for the same host and context path. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 11:12:35 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 4 Nov 2014 11:12:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4051) Use descriptive error message for duplicate host/context deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-4051: --------------------------------- Assignee: Tomaz Cerar (was: Stuart Douglas) > Use descriptive error message for duplicate host/context deployments > -------------------------------------------------------------------- > > Key: WFLY-4051 > URL: https://issues.jboss.org/browse/WFLY-4051 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Priority: Minor > > If a user attempts to deploy a web application to a host/context to which another application is deployed, this will fail for obvious reasons. > What isn't obvious is the error message. Currently, users will see a DuplicateServiceException. Ideally, the error message should indicate that another application is deployed for the same host and context path. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 11:37:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Nov 2014 11:37:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3900) Unable to inject EJB Context into CDI Interceptor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017236#comment-13017236 ] RH Bugzilla Integration commented on WFLY-3900: ----------------------------------------------- Ron ?meral changed the Status of [bug 1149644|https://bugzilla.redhat.com/show_bug.cgi?id=1149644] from ON_QA to VERIFIED > Unable to inject EJB Context into CDI Interceptor > ------------------------------------------------- > > Key: WFLY-3900 > URL: https://issues.jboss.org/browse/WFLY-3900 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > Attachments: inject-ejb-context-into-cdi-interceptor.jar, server.log > > > CDI Interceptor cannot inject EJB session context. > If the Interceptor is changed to EJB interceptor by removing the @Interceptor on the interceptor and removing it from the beans.xml, and adding @Interceptors(...) to the EJB, then it is able to inject. > See attached reproducer with source and log file. > private @Resource SessionContext sessionContext; > Caused by: javax.naming.NameNotFoundException: env/test.ServiceLoggedInterceptor/sessionContext -- service jboss.naming.context.java.comp.inject-ejb-context-into-cdi-interceptor.inject-ejb-context-into-cdi-interceptor.HelloEJB.env."test.ServiceLoggedInterceptor".sessionContext > at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) [wildfly-naming-9.0.0.Alpha1.jar:9.0.0.Alpha1] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] > at org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices.resolveResource(WeldResourceInjectionServices.java:185) > ... 127 more -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 12:42:36 2014 From: issues at jboss.org (Mathieu Lachance (JIRA)) Date: Tue, 4 Nov 2014 12:42:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-209) do not export api if excluded within jboss-deployment-structure.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Lachance updated WFCORE-209: ------------------------------------ Workaround Description: *workaround 1* update the javaee/api/main.module.xml as followed: {code:xml} {code} though this is non-portable. *workaround 2* update jboss-deployment-structure.xml as followed: {code:xml} {code} this is fully portable was: update the javaee/api/main.module.xml as followed: {code:xml} {code} though this is non-portable. > do not export api if excluded within jboss-deployment-structure.xml > ------------------------------------------------------------------- > > Key: WFCORE-209 > URL: https://issues.jboss.org/browse/WFCORE-209 > Project: WildFly Core > Issue Type: Bug > Components: Server > Environment: JBoss EAP 6.3 + Spring 3.2.11.RELEASE > Reporter: Mathieu Lachance > > I'm currently trying to upgrade JPA 2.0 to JPA 2.1 in JBoss EAP 6.3 by leveraging the jboss-deployment-structure.xml: > {code:xml} > > > > > > > > > > > > > > > {code} > When trying to deploy my war (containing all hibernate 4.3.6 jars) I get the following error: > {quote} > Caused by: java.lang.NoSuchMethodError: javax.persistence.Table.indexes()[Ljavax/persistence/Index; > at org.hibernate.cfg.annotations.EntityBinder.processComplementaryTableDefinitions(EntityBinder.java:936) [hibernate-core-4.3.6.Final.jar:4.3.6.Final] > at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:824) [hibernate-core-4.3.6.Final.jar:4.3.6.Final] > at org.hibernate.cfg.Configuration$MetadataSourceQueue.processAnnotatedClassesQueue(Configuration.java:3788) [hibernate-core-4.3.6.Final.jar:4.3.6.Final] > at org.hibernate.cfg.Configuration$MetadataSourceQueue.processMetadata(Configuration.java:3742) [hibernate-core-4.3.6.Final.jar:4.3.6.Final] > at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1410) [hibernate-core-4.3.6.Final.jar:4.3.6.Final] > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1844) [hibernate-core-4.3.6.Final.jar:4.3.6.Final] > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:850) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final] > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:843) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final] > at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:398) [hibernate-core-4.3.6.Final.jar:4.3.6.Final] > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:842) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final] > at org.hibernate.jpa.HibernatePersistenceProvider.createContainerEntityManagerFactory(HibernatePersistenceProvider.java:152) [hibernate-entitymanager-4.3.6.Final.jar:4.3.6.Final] > at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:290) [spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE] > at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:310) [spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE] > at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1573) [spring-beans-3.2.11.RELEASE.jar:3.2.11.RELEASE] > at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1511) [spring-beans-3.2.11.RELEASE.jar:3.2.11.RELEASE] > ... 23 more > {quote} > {{Index}} was introduced with JPA 2.1 and even though: > 1. my application bundle the correct JPA jar > 2. my application excluded the javax.persistence.api > 3. my application excluded the jpa subsystem > I get a conflict. > The only way I made it possible to upgrade the JPA version was to explicitely state to not export the javax.persistence.api (see workaround). This way of doing thing though is not portable (as it impacts all other war deployed in the JBoss server) and is critical in our situation. > The issue might/is probably not be related to jboss-modules component but I was not able to find within the jboss sources the explicit line of code responsible of reading the jboss-deployment-structure.xml. > If you can point me out the correct component it will be a pleasure to help resolve the issue. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 12:59:36 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 4 Nov 2014 12:59:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called before all persistence units have performed database updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated WFLY-3619: ----------------------------------- Forum Reference: https://community.jboss.org/message/880815#880815, https://developer.jboss.org/thread/248287 (was: https://community.jboss.org/message/880815#880815) > XA END / un-enlist for database connection called before all persistence units have performed database updates > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3619 > URL: https://issues.jboss.org/browse/WFLY-3619 > Project: WildFly > Issue Type: Bug > Components: EJB, JCA, JPA / Hibernate, Transactions > Affects Versions: 8.0.0.Final > Environment: Windows 7 64-bit > JDK 1.8.0_05-b13 64-Bit > MS SQL Server 2012 database > Latest MS JDBC driver > XA datasource > Reporter: Andreas Liebscher > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > Attachments: persistence.xml, server-9.0.0.Alpha1-SNAPHOT-trace.log, server-9.0.0.Alpha1-SNAPHOT.log, server-all-traces-full.log.gz, server-org-jboss-as-jpa.log, server.jca.log, server_MSSQL_Trace.log > > > While trying to port an EE application from JBoss5 to WF8 the following problem occurred: > EJBs (@Required) using JPA to do some data changes. > Some changes get already written to the database, others reside in the session cache. > After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion. > Then more changes are flushed to the database, but I run in a reproduceable database locking problem. > After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call. > There should be exactly one xa transaction active processing all data changes. > But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction. > After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour: > - a connection is enlisted and xa start called > - the same connection is used for several select / insert / update statements > - after return of the top EJB call on the same connection xa end and connection un-enlist is called > - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected. > Shouldn't xa end be called AFTER beforeCompletion / session flush!?! -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 13:20:35 2014 From: issues at jboss.org (Stan Silvert (JIRA)) Date: Tue, 4 Nov 2014 13:20:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-217) CLI upload for op params with ModelType.BYTES In-Reply-To: References: Message-ID: Stan Silvert created WFCORE-217: ----------------------------------- Summary: CLI upload for op params with ModelType.BYTES Key: WFCORE-217 URL: https://issues.jboss.org/browse/WFCORE-217 Project: WildFly Core Issue Type: Feature Request Components: CLI Affects Versions: 1.0.0.Alpha11 Reporter: Stan Silvert Assignee: Stan Silvert Fix For: 1.0.0.Alpha12 This Jira adds the same feature to regular CLI that was added to CLI GUI in WFCORE-204. That is, for any operation who has a parameter type of ModelType.BYTES, treat the user-supplied value as a file path from which to retrieve those bytes. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 13:53:35 2014 From: issues at jboss.org (Ian Kent (JIRA)) Date: Tue, 4 Nov 2014 13:53:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4052) wildfly web management console hangs during deploy from cli In-Reply-To: References: Message-ID: Ian Kent created WFLY-4052: ------------------------------ Summary: wildfly web management console hangs during deploy from cli Key: WFLY-4052 URL: https://issues.jboss.org/browse/WFLY-4052 Project: WildFly Issue Type: Bug Components: Web Console Affects Versions: 8.1.0.Final Reporter: Ian Kent Assignee: Heiko Braun We are running wildfly in domain mode with the following configuration. host A running domain controlller host B running host controller with one app sever host C running host controller with one app server host D running host controller with one app server When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 14:20:36 2014 From: issues at jboss.org (Marek Goldmann (JIRA)) Date: Tue, 4 Nov 2014 14:20:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marek Goldmann resolved WFLY-4044. ---------------------------------- Resolution: Cannot Reproduce Bug If you want to run it as a different user, from different location, please take a look at {{/usr/bin/wildfly-cp}} script. The systemd service is meant to run applications, for example when you use Fedora as a host operating system. In other cases the {{wildfly-cp}} is the way to go. I'm resolving this issue now. > Wildfly service will not start on fedora 20 - 64 bit > ---------------------------------------------------- > > Key: WFLY-4044 > URL: https://issues.jboss.org/browse/WFLY-4044 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Environment: Fedora 20 - updates installed > Reporter: Karl Nicholas > Assignee: Marek Goldmann > > standalone.sh starts wildfly ok but systemctl start service fails: > [root at localhost system]# yum install wildfly > Loaded plugins: langpacks, refresh-packagekit > Package wildfly-8.1.0-3.fc20.noarch already installed and latest version > Nothing to do > [root at localhost system]# systemctl start wildfly > [root at localhost system]# systemctl status wildfly > wildfly.service - The WildFly Application Server > Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) > Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago > Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) > Main PID: 7658 (code=exited, status=1/FAILURE) > Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. > Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE > Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. > [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 14:25:35 2014 From: issues at jboss.org (Karl Nicholas (JIRA)) Date: Tue, 4 Nov 2014 14:25:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017271#comment-13017271 ] Karl Nicholas commented on WFLY-4044: ------------------------------------- Thanks for the update. As a point of order, if you can the time to answer, I installed a second copy of wilfdly in my local directory to use for development with Eclipse. Is that the 'recommended' way to develop? > Wildfly service will not start on fedora 20 - 64 bit > ---------------------------------------------------- > > Key: WFLY-4044 > URL: https://issues.jboss.org/browse/WFLY-4044 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Environment: Fedora 20 - updates installed > Reporter: Karl Nicholas > Assignee: Marek Goldmann > > standalone.sh starts wildfly ok but systemctl start service fails: > [root at localhost system]# yum install wildfly > Loaded plugins: langpacks, refresh-packagekit > Package wildfly-8.1.0-3.fc20.noarch already installed and latest version > Nothing to do > [root at localhost system]# systemctl start wildfly > [root at localhost system]# systemctl status wildfly > wildfly.service - The WildFly Application Server > Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) > Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago > Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) > Main PID: 7658 (code=exited, status=1/FAILURE) > Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. > Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE > Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. > [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 14:37:35 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Tue, 4 Nov 2014 14:37:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed JBLOGGING-111. ----------------------------------- Resolution: Rejected The internal providers are not meant to be exposed and therefore as you see won't work with a service loader. If you need a provided provider you can explicitly set the {{org.jboss.logging.provider}} system property. The allowed values are: * jboss * jdk * log4j2 * log4j * slf4j The service loader should only be used if one of the above use cases does not fit your needs. > LoggerProvider configured with new ServiceLoader crash > ------------------------------------------------------ > > Key: JBLOGGING-111 > URL: https://issues.jboss.org/browse/JBLOGGING-111 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Beta1 > Environment: Weblogic 10.3.2.0 > Configured in ejb jar, deployed by an ear file > Reporter: Frederic Allard > Assignee: James Perkins > > There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging. > org.jboss.logging.LoggerProviders snippet : > {code} > // Next try for a service provider > try { > final ServiceLoader loader = ServiceLoader.load(LoggerProvider.class, cl); > if (loader.iterator().hasNext()) { > return loader.iterator().next(); > } > } catch (Throwable ignore) { > // TODO consider printing the stack trace as it should only happen once > } > {code} > When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider. > {code} > java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers "" > at java.util.ServiceLoader.fail(ServiceLoader.java:207) > at java.util.ServiceLoader.access$100(ServiceLoader.java:164) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) > at java.util.ServiceLoader$1.next(ServiceLoader.java:421) > at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70) > at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32) > at org.jboss.logging.LoggerProviders.(LoggerProviders.java:29) > at org.jboss.logging.Logger.getLogger(Logger.java:2177) > at org.jboss.logging.Logger$1.run(Logger.java:2277) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228) > at org.hibernate.cfg.Configuration.(Configuration.java:176) > ... > {code} > This is caused by the fact that all JBoss providers are not public classes and are instead package classes. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 15:34:35 2014 From: issues at jboss.org (Frederic Allard (JIRA)) Date: Tue, 4 Nov 2014 15:34:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017282#comment-13017282 ] Frederic Allard commented on JBLOGGING-111: ------------------------------------------- A system property is not a good solution for a enterprise application packaged as a war or ear file. > LoggerProvider configured with new ServiceLoader crash > ------------------------------------------------------ > > Key: JBLOGGING-111 > URL: https://issues.jboss.org/browse/JBLOGGING-111 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Beta1 > Environment: Weblogic 10.3.2.0 > Configured in ejb jar, deployed by an ear file > Reporter: Frederic Allard > Assignee: James Perkins > > There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging. > org.jboss.logging.LoggerProviders snippet : > {code} > // Next try for a service provider > try { > final ServiceLoader loader = ServiceLoader.load(LoggerProvider.class, cl); > if (loader.iterator().hasNext()) { > return loader.iterator().next(); > } > } catch (Throwable ignore) { > // TODO consider printing the stack trace as it should only happen once > } > {code} > When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider. > {code} > java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers "" > at java.util.ServiceLoader.fail(ServiceLoader.java:207) > at java.util.ServiceLoader.access$100(ServiceLoader.java:164) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) > at java.util.ServiceLoader$1.next(ServiceLoader.java:421) > at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70) > at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32) > at org.jboss.logging.LoggerProviders.(LoggerProviders.java:29) > at org.jboss.logging.Logger.getLogger(Logger.java:2177) > at org.jboss.logging.Logger$1.run(Logger.java:2277) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228) > at org.hibernate.cfg.Configuration.(Configuration.java:176) > ... > {code} > This is caused by the fact that all JBoss providers are not public classes and are instead package classes. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 16:08:35 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Tue, 4 Nov 2014 16:08:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4053) Upgrade Infinispan to 7.0.0.Final In-Reply-To: References: Message-ID: Paul Ferraro created WFLY-4053: ---------------------------------- Summary: Upgrade Infinispan to 7.0.0.Final Key: WFLY-4053 URL: https://issues.jboss.org/browse/WFLY-4053 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 9.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 16:11:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 4 Nov 2014 16:11:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3937) Jackson libs are Private, should be Public In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017287#comment-13017287 ] RH Bugzilla Integration commented on WFLY-3937: ----------------------------------------------- Kabir Khan changed the Status of [bug 1094937|https://bugzilla.redhat.com/show_bug.cgi?id=1094937] from POST to MODIFIED > Jackson libs are Private, should be Public > ------------------------------------------ > > Key: WFLY-3937 > URL: https://issues.jboss.org/browse/WFLY-3937 > Project: WildFly > Issue Type: Bug > Environment: EAP 6.3.0.ER2 > Reporter: Marek Novotny > Assignee: Marek Novotny > Fix For: 9.0.0.Beta1 > > > The following libraries have their module.xml files set to *private*: > * org.codehaus.jackson.jackson-core-asl > * org.codehaus.jackson.jackson-mapper-asl > * org.codehaus.jackson.jackson-jaxrs > * org.codehaus.jackson.jackson-xc > After talking with [~bill.burke], these should be *public*. > While these modules are private, the use of them creates WARNings in the stack trace. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 16:36:36 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Tue, 4 Nov 2014 16:36:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins reopened JBLOGGING-111: ------------------------------------- Yeah, true. I'm a bit hesitant to make these public though. I'll reopen and see if I can think of a better way. The SPI is really meant to enable users to provide their own provider. > LoggerProvider configured with new ServiceLoader crash > ------------------------------------------------------ > > Key: JBLOGGING-111 > URL: https://issues.jboss.org/browse/JBLOGGING-111 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Beta1 > Environment: Weblogic 10.3.2.0 > Configured in ejb jar, deployed by an ear file > Reporter: Frederic Allard > Assignee: James Perkins > > There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging. > org.jboss.logging.LoggerProviders snippet : > {code} > // Next try for a service provider > try { > final ServiceLoader loader = ServiceLoader.load(LoggerProvider.class, cl); > if (loader.iterator().hasNext()) { > return loader.iterator().next(); > } > } catch (Throwable ignore) { > // TODO consider printing the stack trace as it should only happen once > } > {code} > When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider. > {code} > java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers "" > at java.util.ServiceLoader.fail(ServiceLoader.java:207) > at java.util.ServiceLoader.access$100(ServiceLoader.java:164) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) > at java.util.ServiceLoader$1.next(ServiceLoader.java:421) > at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70) > at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32) > at org.jboss.logging.LoggerProviders.(LoggerProviders.java:29) > at org.jboss.logging.Logger.getLogger(Logger.java:2177) > at org.jboss.logging.Logger$1.run(Logger.java:2277) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228) > at org.hibernate.cfg.Configuration.(Configuration.java:176) > ... > {code} > This is caused by the fact that all JBoss providers are not public classes and are instead package classes. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 17:02:35 2014 From: issues at jboss.org (Frederic Allard (JIRA)) Date: Tue, 4 Nov 2014 17:02:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017302#comment-13017302 ] Frederic Allard commented on JBLOGGING-111: ------------------------------------------- Thx for looking to it :) Fr?d?ric Allard Sun Certified Programmer for Java 2 Platform 1.4 Cellulaire : 418 265-3329 psychobaatezu at gmail.com > LoggerProvider configured with new ServiceLoader crash > ------------------------------------------------------ > > Key: JBLOGGING-111 > URL: https://issues.jboss.org/browse/JBLOGGING-111 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Beta1 > Environment: Weblogic 10.3.2.0 > Configured in ejb jar, deployed by an ear file > Reporter: Frederic Allard > Assignee: James Perkins > > There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging. > org.jboss.logging.LoggerProviders snippet : > {code} > // Next try for a service provider > try { > final ServiceLoader loader = ServiceLoader.load(LoggerProvider.class, cl); > if (loader.iterator().hasNext()) { > return loader.iterator().next(); > } > } catch (Throwable ignore) { > // TODO consider printing the stack trace as it should only happen once > } > {code} > When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider. > {code} > java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers "" > at java.util.ServiceLoader.fail(ServiceLoader.java:207) > at java.util.ServiceLoader.access$100(ServiceLoader.java:164) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) > at java.util.ServiceLoader$1.next(ServiceLoader.java:421) > at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70) > at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32) > at org.jboss.logging.LoggerProviders.(LoggerProviders.java:29) > at org.jboss.logging.Logger.getLogger(Logger.java:2177) > at org.jboss.logging.Logger$1.run(Logger.java:2277) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228) > at org.hibernate.cfg.Configuration.(Configuration.java:176) > ... > {code} > This is caused by the fact that all JBoss providers are not public classes and are instead package classes. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 18:32:35 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 4 Nov 2014 18:32:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-177) Intermittent failure in DomainGracefulShutdownTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017311#comment-13017311 ] Stuart Douglas commented on WFCORE-177: --------------------------------------- The issue looks to be 1, I have changed the latch release to be done after the relevant request has been written out > Intermittent failure in DomainGracefulShutdownTestCase > ------------------------------------------------------ > > Key: WFCORE-177 > URL: https://issues.jboss.org/browse/WFCORE-177 > Project: WildFly Core > Issue Type: Bug > Reporter: Brian Stansberry > Assignee: Stuart Douglas > > Intermittent failure, e.g. > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WildFlyCore_PullRequest&buildId=26382 > Test history shows a couple other failures. > Looking at the server logs for that failure, I see this in the main-one log: > {code} > 18:53:21,273 INFO [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0010: Deployed "web-suspend.jar" (runtime-name : "web-suspend.jar") > 18:53:21,297 INFO [stdout] (XNIO-1 task-1) Attempting 1 HttpServerExchange{ GET /web-suspend} > 18:53:22,287 INFO [org.jboss.as.server] (ServerService Thread Pool -- 5) WFLYSRV0211: Suspending server > 18:53:22,338 INFO [stdout] (XNIO-1 task-2) Attempting 2 HttpServerExchange{ GET /web-suspend} > 18:53:22,345 INFO [stdout] (XNIO-1 I/O-1) Rejected 2 HttpServerExchange{ GET /web-suspend} > 18:53:22,351 INFO [stdout] (XNIO-1 task-4) Skipping request 3 HttpServerExchange{ GET /web-suspend} > 18:53:22,391 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment web-suspend.jar (runtime-name: web-suspend.jar) in 6ms > 18:53:22,460 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0050: WildFly Core 1.0.0.Alpha10-SNAPSHOT "Kenny" stopped in 20ms > {code} > Note the "Skipping request 3" line -- so that request was received. > The client side failure though was as if the connection was refused: > {code} > java.io.IOException: java.util.concurrent.ExecutionException: java.net.ConnectException: Connection refused > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:202) > at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:50) > at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:80) > at org.jboss.as.test.integration.domain.suspendresume.DomainGracefulShutdownTestCase.testGracefulShutdownDomainLevel(DomainGracefulShutdownTestCase.java:129) > Caused by: java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.socketConnect(Native Method) > at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) > at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) > at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:579) > at java.net.Socket.connect(Socket.java:528) > at sun.net.NetworkClient.doConnect(NetworkClient.java:180) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) > at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) > at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:763) > at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633) > at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323) > at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:468) > at org.jboss.as.test.integration.common.HttpRequest.processResponse(HttpRequest.java:150) > at org.jboss.as.test.integration.common.HttpRequest.access$000(HttpRequest.java:44) > at org.jboss.as.test.integration.common.HttpRequest$1.call(HttpRequest.java:77) > at org.jboss.as.test.integration.common.HttpRequest$1.call(HttpRequest.java:72) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > {code} > So, perhaps: > 1) A race, where unblocking the suspend resulted in the service stopping and the fake undertow going away before the response went out? With the client interpreting that as a connect failure? We've had plenty of those kinds of problems with management ops when we reload/shutdown the server. > 2) The SuspendResumeHandler doesn't actually write any response to request 3, so maybe that's a problem? This seems unlikely, and if it were a problem I'd think it would be consistent. > 3) ??? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 19:44:35 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 4 Nov 2014 19:44:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4022) PARTITION is a reserved word in some databases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas resolved WFLY-4022. ---------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done > PARTITION is a reserved word in some databases > ---------------------------------------------- > > Key: WFLY-4022 > URL: https://issues.jboss.org/browse/WFLY-4022 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 19:45:36 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 4 Nov 2014 19:45:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3976) Memory leak in Websocket implementation (8.1.0 Final) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas resolved WFLY-3976. ---------------------------------- Resolution: Done I can't reproduce on upstream, this is most likely already fixed > Memory leak in Websocket implementation (8.1.0 Final) > ----------------------------------------------------- > > Key: WFLY-3976 > URL: https://issues.jboss.org/browse/WFLY-3976 > Project: WildFly > Issue Type: Bug > Components: Web Sockets > Affects Versions: 8.1.0.Final > Environment: CentOS 7 > Java 1.7.0_65-b17 > Reporter: Veli Cris > Assignee: Stuart Douglas > Priority: Critical > > Creating 100k persistent websockets connections, exchanging small strings (with RemoteEndpoint.Basic) and finally disconnecting all connections the memory grows with ~1GB for each 100k. Basically the test is the following: the clients are connecting and sending a hello message to the server; the server is responding with a welcome string and the clients are disconnecting. > The settings in onOpen() callback are: > session.setMaxBinaryMessageBufferSize(10240); > session.setMaxTextMessageBufferSize(10240); > session.setMaxIdleTimeout(120000); > session.getUserProperties().put("ts", System.currentTimeMillis()); -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 20:01:36 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 4 Nov 2014 20:01:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3971) Jar Services in META-INF/services are not loaded from static modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017316#comment-13017316 ] Stuart Douglas commented on WFLY-3971: -------------------------------------- I actually misspoke in my comments above. SCI's are loaded from META-INF/services, but only from within the deployment. If you just add a META-INF/services file to reference the spring SCI this should work. > Jar Services in META-INF/services are not loaded from static modules > -------------------------------------------------------------------- > > Key: WFLY-3971 > URL: https://issues.jboss.org/browse/WFLY-3971 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Tomas Repel > Assignee: Stuart Douglas > > If the web application (war) uses jar file from static module, the content of META-INF/services has no effect. If the jar is located inside WEB-INF/lib, services are loaded successfully. > Neither adding `Dependencies: my.module.name.com services` into MANIFEST.MF nor adding `services="import"` to jboss-deployment-structure.xml works. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 20:27:35 2014 From: issues at jboss.org (Frederic Allard (JIRA)) Date: Tue, 4 Nov 2014 20:27:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017320#comment-13017320 ] Frederic Allard commented on JBLOGGING-111: ------------------------------------------- I can explain my use case and it's probably not the best solution to use the service loader explicitly, but I think you won't be able to fix our problem for backward compatibility on your side. We have different legacy services using log4j-1.2.6 which is not supported by jboss logging. In our recent services, we use hibernate and slf4j to decouple the log4j-1.2.6 from our services. This way, we will be able to upgrade in the future the version of log4j. The tricky part is that log4j is deployed in the lib directory of the production Web server and we need to use it for the enterprise global logging configuration (homemade console). The problem is in your priority to select the loggerProvider. You begin by looking if the Log4jFactory is in the classloader. And of course in our case, it will find log4j because it's provided by the server. But we use in reality SLF4J, which supports log4j-1.2.6 by putting the trace level logging in the debug level for example. It would be better if you started by looking for SLF4J because it's the abstraction layer. That way in our case, Hibernate would defer to slf4j instead of log4j and it would worked without exception like : "TRACE not found." > LoggerProvider configured with new ServiceLoader crash > ------------------------------------------------------ > > Key: JBLOGGING-111 > URL: https://issues.jboss.org/browse/JBLOGGING-111 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Beta1 > Environment: Weblogic 10.3.2.0 > Configured in ejb jar, deployed by an ear file > Reporter: Frederic Allard > Assignee: James Perkins > > There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging. > org.jboss.logging.LoggerProviders snippet : > {code} > // Next try for a service provider > try { > final ServiceLoader loader = ServiceLoader.load(LoggerProvider.class, cl); > if (loader.iterator().hasNext()) { > return loader.iterator().next(); > } > } catch (Throwable ignore) { > // TODO consider printing the stack trace as it should only happen once > } > {code} > When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider. > {code} > java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers "" > at java.util.ServiceLoader.fail(ServiceLoader.java:207) > at java.util.ServiceLoader.access$100(ServiceLoader.java:164) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) > at java.util.ServiceLoader$1.next(ServiceLoader.java:421) > at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70) > at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32) > at org.jboss.logging.LoggerProviders.(LoggerProviders.java:29) > at org.jboss.logging.Logger.getLogger(Logger.java:2177) > at org.jboss.logging.Logger$1.run(Logger.java:2277) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228) > at org.hibernate.cfg.Configuration.(Configuration.java:176) > ... > {code} > This is caused by the fact that all JBoss providers are not public classes and are instead package classes. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 22:38:35 2014 From: issues at jboss.org (Sai Krishna (JIRA)) Date: Tue, 4 Nov 2014 22:38:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3856) ERROR: XNIO001007: A channel event listener threw an exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017324#comment-13017324 ] Sai Krishna commented on WFLY-3856: ----------------------------------- ?Hi Stuart, I have posted another issue with Client is not getting called @OnMessage. I tried both 8.1 and 9.0 alpha version. https://developer.jboss.org/thread/249933 Any help I can take from you here or you can guide me to the right resource? Thanks Sai On Sun, Sep 14, 2014 at 5:42 PM, Stuart Douglas (JIRA) > ERROR: XNIO001007: A channel event listener threw an exception > -------------------------------------------------------------- > > Key: WFLY-3856 > URL: https://issues.jboss.org/browse/WFLY-3856 > Project: WildFly > Issue Type: Bug > Reporter: Sai Krishna > Assignee: Jason Greene > Fix For: 9.0.0.Alpha1 > > > https://developer.jboss.org/thread/237868 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Nov 4 22:40:35 2014 From: issues at jboss.org (jaikiran pai (JIRA)) Date: Tue, 4 Nov 2014 22:40:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3639) default-web-module doesn't work for non default host In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017325#comment-13017325 ] jaikiran pai commented on WFLY-3639: ------------------------------------ Guruprasad, it's better to create a new forum post explaining your problem, so that it can be discussed in more detail. The forum is here https://developer.jboss.org/en/wildfly/ > default-web-module doesn't work for non default host > ---------------------------------------------------- > > Key: WFLY-3639 > URL: https://issues.jboss.org/browse/WFLY-3639 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > If you use config like this: > {code:xml} > > > {code} > and have apps myapp1.war & myapp2.war deployed myappwar2.war won't be bind to other-host. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 00:50:35 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 5 Nov 2014 00:50:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3962) onComplete for async listeners not always called In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas resolved WFLY-3962. ---------------------------------- Fix Version/s: 8.2.0.CR1 9.0.0.Beta1 Resolution: Done > onComplete for async listeners not always called > ------------------------------------------------ > > Key: WFLY-3962 > URL: https://issues.jboss.org/browse/WFLY-3962 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Heiko Rupp > Assignee: Stuart Douglas > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > I have a servlet filter that does > chain.doFilter(requestWrapper, responseWrapper); > if (request.isAsyncStarted()) { > asyncListener = request.getAsyncContext().createListener(JsonPAsyncListener.class); > request.getAsyncContext().addListener(asyncListener, requestWrapper, responseWrapper); > } > And (sometimes) this works well so that the onComplete() method of the listener is called. > But this does not happen always. In some (repeatable) condition none of the callback methods in my AsyncListener are called. > I was first thinking that the servlet (resteasy) behind chain.doFilter() is so fast that it completes > before I can add the listener. > But then I tried adding a Thread.sleep() in the RE code which did not change anything. > Similar when I do a startAsync() and add the listener before calling chain.doFilter() > This happens both on Wfly 8.0 and 8.1 > Basically it boils down that if the "backend" uses Futures.immediateFuture(result) , onComplete is not called. > I have created a as small as possible war file + a read me on how to drive that via curl. > See https://github.com/pilhuhn/misc/tree/master/web-goo > I just added 2 examples to the readme file that show that if no > wrapping by the filter is requested, the resteasy code works with > both Futures.immediate... and Futures.transform(...) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 00:58:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 00:58:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-201) UnboundedQueueThreadPool's keep-alive param is currently useless In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017329#comment-13017329 ] RH Bugzilla Integration commented on WFCORE-201: ------------------------------------------------ James Livingston changed the Status of [bug 1106790|https://bugzilla.redhat.com/show_bug.cgi?id=1106790] from NEW to ASSIGNED > UnboundedQueueThreadPool's keep-alive param is currently useless > ---------------------------------------------------------------- > > Key: WFCORE-201 > URL: https://issues.jboss.org/browse/WFCORE-201 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 1.0.0.Alpha10 > Reporter: James Livingston > > UnboundedQueueThreadPoolService currently sets the number of core thread and the maximum threads to the same value. As core threads are never removed, the keep-alive time parameter is useless. > Either the core threads should be lowered (to 0?) to allow timeouts, or the keep-alive parameter removed/deprecated. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 01:05:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 01:05:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-201) UnboundedQueueThreadPool's keep-alive param is currently useless In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017330#comment-13017330 ] RH Bugzilla Integration commented on WFCORE-201: ------------------------------------------------ James Livingston changed the Status of [bug 1106790|https://bugzilla.redhat.com/show_bug.cgi?id=1106790] from ASSIGNED to NEW > UnboundedQueueThreadPool's keep-alive param is currently useless > ---------------------------------------------------------------- > > Key: WFCORE-201 > URL: https://issues.jboss.org/browse/WFCORE-201 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 1.0.0.Alpha10 > Reporter: James Livingston > > UnboundedQueueThreadPoolService currently sets the number of core thread and the maximum threads to the same value. As core threads are never removed, the keep-alive time parameter is useless. > Either the core threads should be lowered (to 0?) to allow timeouts, or the keep-alive parameter removed/deprecated. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 02:48:35 2014 From: issues at jboss.org (Avor Nadal (JIRA)) Date: Wed, 5 Nov 2014 02:48:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3765) Runtime modifications in static files of exploded WARs of exploded EARs aren't reflected. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017337#comment-13017337 ] Avor Nadal commented on WFLY-3765: ---------------------------------- Do you know if this fix is going to be backported to the 8 series? Right now one can use Wildfly 9.0.0 Alpha 1 for development, but it would be useful to count with this feature even in production environments. Thank you! > Runtime modifications in static files of exploded WARs of exploded EARs aren't reflected. > ----------------------------------------------------------------------------------------- > > Key: WFLY-3765 > URL: https://issues.jboss.org/browse/WFLY-3765 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: OS: Xubuntu 14.04 64-bit (Linux) > JDK: 1.8.0 Update 20 > Reporter: Avor Nadal > Assignee: Stuart Douglas > Labels: deployment, exploded, undertow > Fix For: 9.0.0.Alpha1 > > > If you put a exploded WAR in $WILDFLY/standalone/deployments/ and modify a static file once the application is deployed and running, such as an HTML or JPEG file, the changes are reflected in the output to the client. However, if the exploded WAR is contained at the same time in a exploded EAR, they aren't. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 02:51:35 2014 From: issues at jboss.org (Takayoshi Kimura (JIRA)) Date: Wed, 5 Nov 2014 02:51:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: Takayoshi Kimura created JGRP-1898: -------------------------------------- Summary: FD_HOST many false suspect with Full GC Key: JGRP-1898 URL: https://issues.jboss.org/browse/JGRP-1898 Project: JGroups Issue Type: Enhancement Affects Versions: 3.5.1 Reporter: Takayoshi Kimura Assignee: Takayoshi Kimura Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. {code} for (h: hosts) { ping_and_update_timestamp(host) } current = System.currentTimeMillis(); for (h: hosts) { compare current and (ping_timestmp + timeout) } {code} Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 02:55:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 02:55:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JGRP-1898: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1159162 > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 03:10:35 2014 From: issues at jboss.org (Takayoshi Kimura (JIRA)) Date: Wed, 5 Nov 2014 03:10:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Takayoshi Kimura updated JGRP-1898: ----------------------------------- Description: Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. {code} for (h: hosts) { ping_and_update_timestamp(host) } current = System.currentTimeMillis(); for (h: hosts) { compare current and (ping_timestmp + timeout) } {code} Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. was: Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. {code} for (h: hosts) { ping_and_update_timestamp(host) } current = System.currentTimeMillis(); for (h: hosts) { compare current and (ping_timestmp + timeout) } {code} Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 03:15:40 2014 From: issues at jboss.org (Takayoshi Kimura (JIRA)) Date: Wed, 5 Nov 2014 03:15:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Takayoshi Kimura updated JGRP-1898: ----------------------------------- Git Pull Request: https://github.com/belaban/JGroups/pull/180 > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 03:17:35 2014 From: issues at jboss.org (SBS JIRA Integration (JIRA)) Date: Wed, 5 Nov 2014 03:17:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3765) Runtime modifications in static files of exploded WARs of exploded EARs aren't reflected. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SBS JIRA Integration updated WFLY-3765: --------------------------------------- Forum Reference: https://community.jboss.org/message/901834, https://developer.jboss.org/message/901715#901715 (was: https://community.jboss.org/message/901834) > Runtime modifications in static files of exploded WARs of exploded EARs aren't reflected. > ----------------------------------------------------------------------------------------- > > Key: WFLY-3765 > URL: https://issues.jboss.org/browse/WFLY-3765 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: OS: Xubuntu 14.04 64-bit (Linux) > JDK: 1.8.0 Update 20 > Reporter: Avor Nadal > Assignee: Stuart Douglas > Labels: deployment, exploded, undertow > Fix For: 9.0.0.Alpha1 > > > If you put a exploded WAR in $WILDFLY/standalone/deployments/ and modify a static file once the application is deployed and running, such as an HTML or JPEG file, the changes are reflected in the output to the client. However, if the exploded WAR is contained at the same time in a exploded EAR, they aren't. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 03:24:35 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Wed, 5 Nov 2014 03:24:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4035) Upgrade HornetQ to 2.4.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil updated WFLY-4035: ------------------------------ Issue Type: Component Upgrade (was: Feature Request) > Upgrade HornetQ to 2.4.5 > ------------------------ > > Key: WFLY-4035 > URL: https://issues.jboss.org/browse/WFLY-4035 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Clebert Suconic > Assignee: Clebert Suconic > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 03:24:36 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Wed, 5 Nov 2014 03:24:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4035) Upgrade HornetQ to 2.4.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil resolved WFLY-4035. ------------------------------- Resolution: Done PR merged in master and 8.x branches > Upgrade HornetQ to 2.4.5 > ------------------------ > > Key: WFLY-4035 > URL: https://issues.jboss.org/browse/WFLY-4035 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Clebert Suconic > Assignee: Clebert Suconic > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 03:37:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 03:37:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-215) Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017351#comment-13017351 ] RH Bugzilla Integration commented on WFCORE-215: ------------------------------------------------ Marek Kopecky changed the Status of [bug 1159814|https://bugzilla.redhat.com/show_bug.cgi?id=1159814] from ON_QA to VERIFIED > Add a regression test for auditlog-to-TLS-syslog "plain-TCP" issue > ------------------------------------------------------------------ > > Key: WFCORE-215 > URL: https://issues.jboss.org/browse/WFCORE-215 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > Add a regression test for https://issues.jboss.org/browse/WFCORE-190 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 03:52:35 2014 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 5 Nov 2014 03:52:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem In-Reply-To: References: Message-ID: Amos Feng created WFLY-4054: ------------------------------- Summary: Unexpected attribute can be added to elements in Transactions Subsystem Key: WFLY-4054 URL: https://issues.jboss.org/browse/WFLY-4054 Project: WildFly Issue Type: Bug Components: Transactions Reporter: Amos Feng Assignee: Amos Feng If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 03:53:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 03:53:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4054: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1156032 > Unexpected attribute can be added to elements in Transactions Subsystem > ----------------------------------------------------------------------- > > Key: WFLY-4054 > URL: https://issues.jboss.org/browse/WFLY-4054 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. > When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 04:29:36 2014 From: issues at jboss.org (=?UTF-8?Q?Sebastian_=C5=81askawiec_=28JIRA=29?=) Date: Wed, 5 Nov 2014 04:29:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4031) Wildfly Quickstarts using old namespaces for beans.xml and faces-config.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastian ?askawiec closed WFLY-4031. ------------------------------------- > Wildfly Quickstarts using old namespaces for beans.xml and faces-config.xml > --------------------------------------------------------------------------- > > Key: WFLY-4031 > URL: https://issues.jboss.org/browse/WFLY-4031 > Project: WildFly > Issue Type: Bug > Reporter: Rafael Benevides > Assignee: Sebastian ?askawiec > Priority: Minor > Labels: quickstarts, > > All Wildfly quickstarts have the wrong XML namespaces for the following files. > ./src/main/webapp/WEB-INF/beans.xml > ./src/main/webapp/WEB-INF/faces-config.xml > beans.xml and faces-config.xml are using java.sun.com-style namespaces instead of xmlns.jcp.org-style namespaces. > This affects the wildfly archetypes as well -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 04:51:35 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 5 Nov 2014 04:51:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4046) Container lifecycle event method invoked outside of extension observer method invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016684#comment-13016684 ] Thomas Diesler edited comment on WFLY-4046 at 11/5/14 4:51 AM: --------------------------------------------------------------- To reproduce, build: https://github.com/wildflyext/wildfly-camel/tree/2.0 was (Author: thomas.diesler): To reproduce, build: https://github.com/tdiesler/wildfly-camel/tree/2.0 > Container lifecycle event method invoked outside of extension observer method invocation > ---------------------------------------------------------------------------------------- > > Key: WFLY-4046 > URL: https://issues.jboss.org/browse/WFLY-4046 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Thomas Diesler > Assignee: Jozef Hartinger > > Cannot deploy war that uses camel-cdi > This works in 8.1.0.Final > {code} > org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. > at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) > at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) > at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) > at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) > at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) > {code} > Cross Issue: https://issues.apache.org/jira/browse/CAMEL-7992 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 04:53:37 2014 From: issues at jboss.org (Marek Goldmann (JIRA)) Date: Wed, 5 Nov 2014 04:53:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4044) Wildfly service will not start on fedora 20 - 64 bit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017379#comment-13017379 ] Marek Goldmann commented on WFLY-4044: -------------------------------------- The intended way to develop is to use the {{wildfly-cp}} script and create an environment somewhere in your home directory. This way you share the base libraries with the host OS, but you do not mess it by running as a different user :) You point Eclipse to the new directory created by {{wildfly-cp}}. If there are any issues - they should be reported in [Bugzilla, for the wildfly component|https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=wildfly]. > Wildfly service will not start on fedora 20 - 64 bit > ---------------------------------------------------- > > Key: WFLY-4044 > URL: https://issues.jboss.org/browse/WFLY-4044 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Environment: Fedora 20 - updates installed > Reporter: Karl Nicholas > Assignee: Marek Goldmann > > standalone.sh starts wildfly ok but systemctl start service fails: > [root at localhost system]# yum install wildfly > Loaded plugins: langpacks, refresh-packagekit > Package wildfly-8.1.0-3.fc20.noarch already installed and latest version > Nothing to do > [root at localhost system]# systemctl start wildfly > [root at localhost system]# systemctl status wildfly > wildfly.service - The WildFly Application Server > Loaded: loaded (/usr/lib/systemd/system/wildfly.service; disabled) > Active: failed (Result: exit-code) since Sat 2014-11-01 15:50:40 PDT; 5s ago > Process: 7658 ExecStart=/usr/share/wildfly/bin/launch.sh $WILDFLY_MODE $WILDFLY_CONFIG $WILDFLY_BIND (code=exited, status=1/FAILURE) > Main PID: 7658 (code=exited, status=1/FAILURE) > Nov 01 15:50:39 localhost.localdomain systemd[1]: Started The WildFly Application Server. > Nov 01 15:50:40 localhost.localdomain systemd[1]: wildfly.service: main process exited, code=exited, status=1/FAILURE > Nov 01 15:50:40 localhost.localdomain systemd[1]: Unit wildfly.service entered failed state. > [root at localhost system] -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 04:54:35 2014 From: issues at jboss.org (Thomas Diesler (JIRA)) Date: Wed, 5 Nov 2014 04:54:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4046) Container lifecycle event method invoked outside of extension observer method invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Diesler updated WFLY-4046: --------------------------------- Description: Cannot deploy war that uses camel-cdi This works in 8.1.0.Final {code} org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) {code} Camel Issue: https://issues.apache.org/jira/browse/CAMEL-7992 Github Issue: https://github.com/wildflyext/wildfly-camel/issues/52 was: Cannot deploy war that uses camel-cdi This works in 8.1.0.Final {code} org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) {code} Cross Issue: https://issues.apache.org/jira/browse/CAMEL-7992 > Container lifecycle event method invoked outside of extension observer method invocation > ---------------------------------------------------------------------------------------- > > Key: WFLY-4046 > URL: https://issues.jboss.org/browse/WFLY-4046 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Thomas Diesler > Assignee: Jozef Hartinger > > Cannot deploy war that uses camel-cdi > This works in 8.1.0.Final > {code} > org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. > at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) > at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) > at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) > at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) > at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) > {code} > Camel Issue: https://issues.apache.org/jira/browse/CAMEL-7992 > Github Issue: https://github.com/wildflyext/wildfly-camel/issues/52 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 05:27:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 05:27:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3841) double :remove of connection-property from a DS leave it in wrong state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017394#comment-13017394 ] RH Bugzilla Integration commented on WFLY-3841: ----------------------------------------------- Stefano Maestri changed the Status of [bug 1024239|https://bugzilla.redhat.com/show_bug.cgi?id=1024239] from ASSIGNED to POST > double :remove of connection-property from a DS leave it in wrong state > ----------------------------------------------------------------------- > > Key: WFLY-3841 > URL: https://issues.jboss.org/browse/WFLY-3841 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Priority: Critical > Fix For: 9.0.0.CR1 > > > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:add(value=foo) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone at localhost:9990 /] :reload > { > "outcome" => "success", > "result" => undefined > } > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service jboss.data-source-config.ExampleDS.connection-properties.foo was depended upon by service jboss.data-source-config.ExampleDS", > "rolled-back" => true > } > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:remove > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:test-connection-in-pool > { > "outcome" => "failed", > "failure-description" => "WFLYJCA0040: failed to invoke operation: WFLYJCA0042: failed to match pool. Check JndiName: java:jboss/datasources/ExampleDS", > "rolled-back" => true > } -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 05:47:35 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 5 Nov 2014 05:47:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-1898: --------------------------- Fix Version/s: 3.5.2 3.6.1 > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.5.2, 3.6.1 > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 05:51:35 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 5 Nov 2014 05:51:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-1898: --------------------------- Fix Version/s: 3.4.7 > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 06:40:36 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 5 Nov 2014 06:40:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017406#comment-13017406 ] Bela Ban commented on JGRP-1898: -------------------------------- Makes sense. I changed the logic slightly to skip the time check if {{isAlive()}} returned true: no need to check then. Backported to 3.4.7 and 3.5.2. I suggest confirm this works and then I can release 3.4.7. > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 06:43:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 06:43:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-788) PicketBoxSecurityVault is not writing data to store after removing from map in memory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated SECURITY-788: --------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1153614 > PicketBoxSecurityVault is not writing data to store after removing from map in memory > ------------------------------------------------------------------------------------- > > Key: SECURITY-788 > URL: https://issues.jboss.org/browse/SECURITY-788 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: PicketBox_4_0_21.Beta1 > > > PicketBoxSecurityVault is not writing data to store after removing from map in memory. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 06:45:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 5 Nov 2014 06:45:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban resolved JGRP-1898. ---------------------------- Resolution: Done Feel free to reopen if this doesn't work > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Nov 5 08:42:51 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 08:42:51 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-108) Incorrect use of ReloadRequiredWriteAttributeHandler for host resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017510#comment-13017510 ] RH Bugzilla Integration commented on WFCORE-108: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1085228|https://bugzilla.redhat.com/show_bug.cgi?id=1085228] from ON_QA to VERIFIED > Incorrect use of ReloadRequiredWriteAttributeHandler for host resources > ----------------------------------------------------------------------- > > Key: WFCORE-108 > URL: https://issues.jboss.org/browse/WFCORE-108 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Chao Wang > Priority: Critical > Fix For: 1.0.0.Alpha9 > > > ReloadRequiredWriteAttributeHandler inherits the default behavior of AbstractWriteAttributeHandler.requiresRuntime(), which is to only process Stage.RUNTIME if context.isNormalServer(). So any use in host resources needs to override that behavior. This isn't done in at least some places. See https://bugzilla.redhat.com/show_bug.cgi?id=1085228 for an example. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 08:42:51 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 08:42:51 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-108) Incorrect use of ReloadRequiredWriteAttributeHandler for host resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017511#comment-13017511 ] RH Bugzilla Integration commented on WFCORE-108: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1085228|https://bugzilla.redhat.com/show_bug.cgi?id=1085228] from ON_QA to VERIFIED > Incorrect use of ReloadRequiredWriteAttributeHandler for host resources > ----------------------------------------------------------------------- > > Key: WFCORE-108 > URL: https://issues.jboss.org/browse/WFCORE-108 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Chao Wang > Priority: Critical > Fix For: 1.0.0.Alpha9 > > > ReloadRequiredWriteAttributeHandler inherits the default behavior of AbstractWriteAttributeHandler.requiresRuntime(), which is to only process Stage.RUNTIME if context.isNormalServer(). So any use in host resources needs to override that behavior. This isn't done in at least some places. See https://bugzilla.redhat.com/show_bug.cgi?id=1085228 for an example. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 08:42:51 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 08:42:51 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-108) Incorrect use of ReloadRequiredWriteAttributeHandler for host resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017516#comment-13017516 ] RH Bugzilla Integration commented on WFCORE-108: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1085228|https://bugzilla.redhat.com/show_bug.cgi?id=1085228] from ON_QA to VERIFIED > Incorrect use of ReloadRequiredWriteAttributeHandler for host resources > ----------------------------------------------------------------------- > > Key: WFCORE-108 > URL: https://issues.jboss.org/browse/WFCORE-108 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Chao Wang > Priority: Critical > Fix For: 1.0.0.Alpha9 > > > ReloadRequiredWriteAttributeHandler inherits the default behavior of AbstractWriteAttributeHandler.requiresRuntime(), which is to only process Stage.RUNTIME if context.isNormalServer(). So any use in host resources needs to override that behavior. This isn't done in at least some places. See https://bugzilla.redhat.com/show_bug.cgi?id=1085228 for an example. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 08:42:52 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 08:42:52 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-108) Incorrect use of ReloadRequiredWriteAttributeHandler for host resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017520#comment-13017520 ] RH Bugzilla Integration commented on WFCORE-108: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1085228|https://bugzilla.redhat.com/show_bug.cgi?id=1085228] from ON_QA to VERIFIED > Incorrect use of ReloadRequiredWriteAttributeHandler for host resources > ----------------------------------------------------------------------- > > Key: WFCORE-108 > URL: https://issues.jboss.org/browse/WFCORE-108 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Chao Wang > Priority: Critical > Fix For: 1.0.0.Alpha9 > > > ReloadRequiredWriteAttributeHandler inherits the default behavior of AbstractWriteAttributeHandler.requiresRuntime(), which is to only process Stage.RUNTIME if context.isNormalServer(). So any use in host resources needs to override that behavior. This isn't done in at least some places. See https://bugzilla.redhat.com/show_bug.cgi?id=1085228 for an example. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 08:51:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 08:51:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-108) Incorrect use of ReloadRequiredWriteAttributeHandler for host resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017521#comment-13017521 ] RH Bugzilla Integration commented on WFCORE-108: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1085228|https://bugzilla.redhat.com/show_bug.cgi?id=1085228] from ON_QA to VERIFIED > Incorrect use of ReloadRequiredWriteAttributeHandler for host resources > ----------------------------------------------------------------------- > > Key: WFCORE-108 > URL: https://issues.jboss.org/browse/WFCORE-108 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Chao Wang > Priority: Critical > Fix For: 1.0.0.Alpha9 > > > ReloadRequiredWriteAttributeHandler inherits the default behavior of AbstractWriteAttributeHandler.requiresRuntime(), which is to only process Stage.RUNTIME if context.isNormalServer(). So any use in host resources needs to override that behavior. This isn't done in at least some places. See https://bugzilla.redhat.com/show_bug.cgi?id=1085228 for an example. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 09:53:29 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 5 Nov 2014 09:53:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1899) Discovery returns after 16 responses even if there are no coord responses In-Reply-To: References: Message-ID: Bela Ban created JGRP-1899: ------------------------------ Summary: Discovery returns after 16 responses even if there are no coord responses Key: JGRP-1899 URL: https://issues.jboss.org/browse/JGRP-1899 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.1 Discovery sets {{Responses.num_expected_rsps}} to 16 if no member list is defined. This makes discovery return after 16 responses even if no response from a coordinator has been received. This is a problem if we have a cluster of size > 16 and the coordinator doesn't respond imediately, e.g. because it is busy processing other requests. h5. Solution * Set {{num_expected_rsps}} to 0 (= wait until at least 1 coord rsp has been received -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 09:56:30 2014 From: issues at jboss.org (Frederic Allard (JIRA)) Date: Wed, 5 Nov 2014 09:56:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017320#comment-13017320 ] Frederic Allard edited comment on JBLOGGING-111 at 11/5/14 9:55 AM: -------------------------------------------------------------------- I can explain my use case and it's probably not the best solution to use the service loader explicitly, but I think you won't be able to fix our problem for backward compatibility on your side. We have different legacy services using log4j-1.2.6 which is not supported by jboss logging. In our recent services, we use hibernate and slf4j to decouple the log4j-1.2.6 from our services. This way, we will be able to upgrade in the future the version of log4j. The tricky part is that log4j is deployed in the lib directory of the production Web server and we need to use it for the enterprise global logging configuration (homemade console). The problem is in your priority to select the loggerProvider. You begin by looking if the Log4jFactory is in the classloader. And of course in our case, it will find log4j because it's provided by the server. But we use in reality SLF4J, which supports log4j-1.2.6 by putting the trace level logging in the debug level for example. It would be better if you started by looking for SLF4J because it's the abstraction layer. That way in our case, Hibernate would defer to slf4j instead of log4j and it would work without exception like : "TRACE not found." was (Author: psychobaatezu): I can explain my use case and it's probably not the best solution to use the service loader explicitly, but I think you won't be able to fix our problem for backward compatibility on your side. We have different legacy services using log4j-1.2.6 which is not supported by jboss logging. In our recent services, we use hibernate and slf4j to decouple the log4j-1.2.6 from our services. This way, we will be able to upgrade in the future the version of log4j. The tricky part is that log4j is deployed in the lib directory of the production Web server and we need to use it for the enterprise global logging configuration (homemade console). The problem is in your priority to select the loggerProvider. You begin by looking if the Log4jFactory is in the classloader. And of course in our case, it will find log4j because it's provided by the server. But we use in reality SLF4J, which supports log4j-1.2.6 by putting the trace level logging in the debug level for example. It would be better if you started by looking for SLF4J because it's the abstraction layer. That way in our case, Hibernate would defer to slf4j instead of log4j and it would worked without exception like : "TRACE not found." > LoggerProvider configured with new ServiceLoader crash > ------------------------------------------------------ > > Key: JBLOGGING-111 > URL: https://issues.jboss.org/browse/JBLOGGING-111 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Beta1 > Environment: Weblogic 10.3.2.0 > Configured in ejb jar, deployed by an ear file > Reporter: Frederic Allard > Assignee: James Perkins > > There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging. > org.jboss.logging.LoggerProviders snippet : > {code} > // Next try for a service provider > try { > final ServiceLoader loader = ServiceLoader.load(LoggerProvider.class, cl); > if (loader.iterator().hasNext()) { > return loader.iterator().next(); > } > } catch (Throwable ignore) { > // TODO consider printing the stack trace as it should only happen once > } > {code} > When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider. > {code} > java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers "" > at java.util.ServiceLoader.fail(ServiceLoader.java:207) > at java.util.ServiceLoader.access$100(ServiceLoader.java:164) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) > at java.util.ServiceLoader$1.next(ServiceLoader.java:421) > at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70) > at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32) > at org.jboss.logging.LoggerProviders.(LoggerProviders.java:29) > at org.jboss.logging.Logger.getLogger(Logger.java:2177) > at org.jboss.logging.Logger$1.run(Logger.java:2277) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228) > at org.hibernate.cfg.Configuration.(Configuration.java:176) > ... > {code} > This is caused by the fact that all JBoss providers are not public classes and are instead package classes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 10:08:29 2014 From: issues at jboss.org (Farah Juma (JIRA)) Date: Wed, 5 Nov 2014 10:08:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2339) Error occurs when a deployment contains two WARs that each need a different JSF implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017555#comment-13017555 ] Farah Juma commented on WFLY-2339: ---------------------------------- Using a jboss-deployment-structure.xml file similar to the one below should allow an EAR with two WARs that each require a different JSF version to be deployed successfully (the file below uses Mojarra 2.1.26 and Mojarra 2.1.27 as an example): {code:xml} {code} Note that {{org.jboss.jbossfaces.JSF_CONFIG_NAME}} and {{WAR_BUNDLES_JSF_IMPL}} should _not_ be included in the web.xml for either of the WARs packaged in the EAR. > Error occurs when a deployment contains two WARs that each need a different JSF implementation > ---------------------------------------------------------------------------------------------- > > Key: WFLY-2339 > URL: https://issues.jboss.org/browse/WFLY-2339 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Minor > > A deployment that contains two WARs that each need a different JSF implementation fails to start. As described in the forum post, using jboss-deployment-structure.xml to add the correct dependencies to the two subdeployments doesn't currently work. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 10:09:30 2014 From: issues at jboss.org (Farah Juma (JIRA)) Date: Wed, 5 Nov 2014 10:09:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2339) Error occurs when a deployment contains two WARs that each need a different JSF implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farah Juma resolved WFLY-2339. ------------------------------ Resolution: Rejected > Error occurs when a deployment contains two WARs that each need a different JSF implementation > ---------------------------------------------------------------------------------------------- > > Key: WFLY-2339 > URL: https://issues.jboss.org/browse/WFLY-2339 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Minor > > A deployment that contains two WARs that each need a different JSF implementation fails to start. As described in the forum post, using jboss-deployment-structure.xml to add the correct dependencies to the two subdeployments doesn't currently work. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 10:32:30 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 5 Nov 2014 10:32:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1899) Discovery returns after 16 responses even if there are no coord responses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban resolved JGRP-1899. ---------------------------- Resolution: Done > Discovery returns after 16 responses even if there are no coord responses > ------------------------------------------------------------------------- > > Key: JGRP-1899 > URL: https://issues.jboss.org/browse/JGRP-1899 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > Discovery sets {{Responses.num_expected_rsps}} to 16 if no member list is defined. This makes discovery return after 16 responses even if no response from a coordinator has been received. > This is a problem if we have a cluster of size > 16 and the coordinator doesn't respond imediately, e.g. because it is busy processing other requests. > h5. Solution > * Set {{num_expected_rsps}} to 0 (= wait until at least 1 coord rsp has been received -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 11:41:30 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 5 Nov 2014 11:41:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017585#comment-13017585 ] David Lloyd commented on JBLOGGING-111: --------------------------------------- The root cause here of the actual exception is simply that the service loader loop needs to be modified to look something like this: {code} Iterator it = serviceLoader.blah(); for (;;) try { if (! it.hasNext()) break; LoggerProvider p = it.next(); if (p is okay) break; } catch (ServiceConfigurationError ignored) {} {code} The key is to put hasNext() inside a try/catch which in turn is inside the loop. This will skip failed providers and move on to workable ones. > LoggerProvider configured with new ServiceLoader crash > ------------------------------------------------------ > > Key: JBLOGGING-111 > URL: https://issues.jboss.org/browse/JBLOGGING-111 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Beta1 > Environment: Weblogic 10.3.2.0 > Configured in ejb jar, deployed by an ear file > Reporter: Frederic Allard > Assignee: James Perkins > > There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging. > org.jboss.logging.LoggerProviders snippet : > {code} > // Next try for a service provider > try { > final ServiceLoader loader = ServiceLoader.load(LoggerProvider.class, cl); > if (loader.iterator().hasNext()) { > return loader.iterator().next(); > } > } catch (Throwable ignore) { > // TODO consider printing the stack trace as it should only happen once > } > {code} > When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider. > {code} > java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers "" > at java.util.ServiceLoader.fail(ServiceLoader.java:207) > at java.util.ServiceLoader.access$100(ServiceLoader.java:164) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) > at java.util.ServiceLoader$1.next(ServiceLoader.java:421) > at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70) > at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32) > at org.jboss.logging.LoggerProviders.(LoggerProviders.java:29) > at org.jboss.logging.Logger.getLogger(Logger.java:2177) > at org.jboss.logging.Logger$1.run(Logger.java:2277) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228) > at org.hibernate.cfg.Configuration.(Configuration.java:176) > ... > {code} > This is caused by the fact that all JBoss providers are not public classes and are instead package classes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 12:15:35 2014 From: issues at jboss.org (Wolf-Dieter Fink (JIRA)) Date: Wed, 5 Nov 2014 12:15:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4055) Show more details for the EJB SessionBean statistic In-Reply-To: References: Message-ID: Wolf-Dieter Fink created WFLY-4055: -------------------------------------- Summary: Show more details for the EJB SessionBean statistic Key: WFLY-4055 URL: https://issues.jboss.org/browse/WFLY-4055 Project: WildFly Issue Type: Enhancement Affects Versions: 9.0.0.Alpha1, 8.1.0.Final Reporter: Wolf-Dieter Fink Assignee: Jason Greene The JMX MBeans in former versions <7 show more statistics. As this counters can be important they should be collected in WildFly as well. SLSB: Current- Available- Max- (pool), Remove, Create SFSB: CacheSize, CreateSize, InvocStat, PassivatedCount, Current, RemoveCount, Available, Max, Total As there is no pool possible for SFSB there is no Create and Remove counter for pooling and no counter of current instances. These counters should be added -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 13:42:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 13:42:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3847) AS7BindingRegistry does not respect the SPI contract In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017605#comment-13017605 ] RH Bugzilla Integration commented on WFLY-3847: ----------------------------------------------- Jeff Mesnil changed the Status of [bug 1124178|https://bugzilla.redhat.com/show_bug.cgi?id=1124178] from NEW to POST > AS7BindingRegistry does not respect the SPI contract > ---------------------------------------------------- > > Key: WFLY-3847 > URL: https://issues.jboss.org/browse/WFLY-3847 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > Fix For: 9.0.0.Alpha1 > > > The implementation of AS7BindingRegistry#lookup always return null. > This method is called by HornetQ when JNDI entries for its resources > are updated using its own management API. > We advise against using it in WildFly (and use WildFly own management API) but we must still respect the SPI contract for this method. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 13:51:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 13:51:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3285) Domain directory properties only work on specific operating systems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017608#comment-13017608 ] RH Bugzilla Integration commented on WFLY-3285: ----------------------------------------------- James Perkins changed the Status of [bug 1091198|https://bugzilla.redhat.com/show_bug.cgi?id=1091198] from NEW to ASSIGNED > Domain directory properties only work on specific operating systems > ------------------------------------------------------------------- > > Key: WFLY-3285 > URL: https://issues.jboss.org/browse/WFLY-3285 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.1.0.CR1 > Reporter: Dennis Reed > Assignee: Tomaz Cerar > > domain.sh only parses -Djboss.domain.base.dir, -Djboss.domain.log.dir, and -Djboss.domain.config.dir (used to set -Dlogging.configuration and -Dorg.jboss.boot.log.file) on Linux, Solaris, and OS X. > It does not attempt to parse these (and therefore does not set the logging properties correctly) on any other OS, including AIX. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 14:36:29 2014 From: issues at jboss.org (Farah Juma (JIRA)) Date: Wed, 5 Nov 2014 14:36:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4042) Update JSF based on Mojarra 2.2.9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farah Juma updated WFLY-4042: ----------------------------- Affects Version/s: 9.0.0.Alpha1 > Update JSF based on Mojarra 2.2.9 > --------------------------------- > > Key: WFLY-4042 > URL: https://issues.jboss.org/browse/WFLY-4042 > Project: WildFly > Issue Type: Component Upgrade > Components: JSF > Affects Versions: 9.0.0.Alpha1 > Reporter: Cody Lerum > Assignee: Farah Juma > Fix For: 8.2.0.CR1 > > > Release scheduled for Nov 4 2014 and it would be great to pick this up before 8.2.Final -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 14:36:30 2014 From: issues at jboss.org (Farah Juma (JIRA)) Date: Wed, 5 Nov 2014 14:36:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4042) Update JSF based on Mojarra 2.2.9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Farah Juma updated WFLY-4042: ----------------------------- Fix Version/s: (was: 8.2.0.CR1) > Update JSF based on Mojarra 2.2.9 > --------------------------------- > > Key: WFLY-4042 > URL: https://issues.jboss.org/browse/WFLY-4042 > Project: WildFly > Issue Type: Component Upgrade > Components: JSF > Affects Versions: 9.0.0.Alpha1 > Reporter: Cody Lerum > Assignee: Farah Juma > > Release scheduled for Nov 4 2014 and it would be great to pick this up before 8.2.Final -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 14:42:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 14:42:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-174) Add periodic-size-rotating-file-handler to the allowed set of files to be read In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017622#comment-13017622 ] RH Bugzilla Integration commented on WFCORE-174: ------------------------------------------------ James Perkins changed the Status of [bug 1153360|https://bugzilla.redhat.com/show_bug.cgi?id=1153360] from ASSIGNED to CLOSED > Add periodic-size-rotating-file-handler to the allowed set of files to be read > ------------------------------------------------------------------------------ > > Key: WFCORE-174 > URL: https://issues.jboss.org/browse/WFCORE-174 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > The {{periodic-size-rotating-file-handler}} needs to be added to the allowed file types to be read and listed with the {{read-log-file}} and {{list-log-files}} operations. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 14:43:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 5 Nov 2014 14:43:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-174) Add periodic-size-rotating-file-handler to the allowed set of files to be read In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFCORE-174. -------------------------------- Resolution: Rejected See https://issues.jboss.org/browse/WFCORE-197 > Add periodic-size-rotating-file-handler to the allowed set of files to be read > ------------------------------------------------------------------------------ > > Key: WFCORE-174 > URL: https://issues.jboss.org/browse/WFCORE-174 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > The {{periodic-size-rotating-file-handler}} needs to be added to the allowed file types to be read and listed with the {{read-log-file}} and {{list-log-files}} operations. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 15:40:29 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 5 Nov 2014 15:40:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4052) wildfly web management console hangs during deploy from cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-4052: ------------------------------ Component/s: Domain Management > wildfly web management console hangs during deploy from cli > ----------------------------------------------------------- > > Key: WFLY-4052 > URL: https://issues.jboss.org/browse/WFLY-4052 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Web Console > Affects Versions: 8.1.0.Final > Reporter: Ian Kent > Assignee: Heiko Braun > > We are running wildfly in domain mode with the following configuration. > host A running domain controlller > host B running host controller with one app sever > host C running host controller with one app server > host D running host controller with one app server > When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 15:41:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 5 Nov 2014 15:41:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-218) wildfly web management console hangs during deploy from cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar moved WFLY-4052 to WFCORE-218: ------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-218 (was: WFLY-4052) Affects Version/s: 1.0.0.Alpha1 (was: 8.1.0.Final) Component/s: Domain Management (was: Web Console) (was: Domain Management) > wildfly web management console hangs during deploy from cli > ----------------------------------------------------------- > > Key: WFCORE-218 > URL: https://issues.jboss.org/browse/WFCORE-218 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha1 > Reporter: Ian Kent > Assignee: Heiko Braun > > We are running wildfly in domain mode with the following configuration. > host A running domain controlller > host B running host controller with one app sever > host C running host controller with one app server > host D running host controller with one app server > When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 15:41:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 5 Nov 2014 15:41:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-218) wildfly web management console hangs during deploy from cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFCORE-218: ---------------------------------- Assignee: Brian Stansberry (was: Heiko Braun) > wildfly web management console hangs during deploy from cli > ----------------------------------------------------------- > > Key: WFCORE-218 > URL: https://issues.jboss.org/browse/WFCORE-218 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha1 > Reporter: Ian Kent > Assignee: Brian Stansberry > > We are running wildfly in domain mode with the following configuration. > host A running domain controlller > host B running host controller with one app sever > host C running host controller with one app server > host D running host controller with one app server > When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 15:57:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 15:57:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2221) NPE in BinderService In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-2221: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1160530 > NPE in BinderService > -------------------- > > Key: WFLY-2221 > URL: https://issues.jboss.org/browse/WFLY-2221 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.0.0.Beta1 > Reporter: Jesper Pedersen > Assignee: Eduardo Martins > Fix For: 8.0.0.CR1 > > > {noformat} > 11:03:33,766 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$BinderReleaseListener at 2d6f9ce1" failed: java.lang.NullPointerException > at org.jboss.as.naming.service.BinderService.release(BinderService.java:100) [wildfly-naming-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$BinderReleaseListener.transition(ModuleJndiBindingProcessor.java:302) [wildfly-ee-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > {noformat} > Master from 3 days ago -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 16:06:29 2014 From: issues at jboss.org (Farah Juma (JIRA)) Date: Wed, 5 Nov 2014 16:06:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4042) Update JSF based on Mojarra 2.2.9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017645#comment-13017645 ] Farah Juma commented on WFLY-4042: ---------------------------------- Looks like the Mojarra 2.2.9 release has been moved to December: https://java.net/jira/browse/JAVASERVERFACES/fixforversion/17040/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel > Update JSF based on Mojarra 2.2.9 > --------------------------------- > > Key: WFLY-4042 > URL: https://issues.jboss.org/browse/WFLY-4042 > Project: WildFly > Issue Type: Component Upgrade > Components: JSF > Affects Versions: 9.0.0.Alpha1 > Reporter: Cody Lerum > Assignee: Farah Juma > > Release scheduled for Nov 4 2014 and it would be great to pick this up before 8.2.Final -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 16:24:37 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 5 Nov 2014 16:24:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-218) wildfly web management console hangs during deploy from cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017648#comment-13017648 ] Brian Stansberry commented on WFCORE-218: ----------------------------------------- Please provide version information, and also thread dumps from each of the hosts (all processes on each host; e.g. from killall -3 java). > wildfly web management console hangs during deploy from cli > ----------------------------------------------------------- > > Key: WFCORE-218 > URL: https://issues.jboss.org/browse/WFCORE-218 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha1 > Reporter: Ian Kent > Assignee: Brian Stansberry > > We are running wildfly in domain mode with the following configuration. > host A running domain controlller > host B running host controller with one app sever > host C running host controller with one app server > host D running host controller with one app server > When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 16:37:29 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 5 Nov 2014 16:37:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3793) Implement transformers for graceful shutdown operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017651#comment-13017651 ] Stuart Douglas commented on WFLY-3793: -------------------------------------- Ops are: :resume-servers() (new op) :suspend-servers(timeout=?) (new op) /server-group=main-server-group:suspend-servers(timeout=?) (new op) /server-group=main-server-group:resume-servers() (new op) /host=master/server-config=server-one:suspend(timeout=?) (new op) /host=master/server-config=server-one:resume(timeout=?) (new op) :stop-servers(blocking=true, timeout=?) (new timeout attribute) /server-group=main-server-group:stop-servers(blocking=true, timeout=?) (new timeout attribute) /host=master/server-config=server-one:stop(timeout=?) (new timeout attribute) > Implement transformers for graceful shutdown operations > ------------------------------------------------------- > > Key: WFLY-3793 > URL: https://issues.jboss.org/browse/WFLY-3793 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 16:37:29 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 5 Nov 2014 16:37:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3793) Implement transformers for graceful shutdown operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas reassigned WFLY-3793: ------------------------------------ Assignee: Brian Stansberry (was: Stuart Douglas) > Implement transformers for graceful shutdown operations > ------------------------------------------------------- > > Key: WFLY-3793 > URL: https://issues.jboss.org/browse/WFLY-3793 > Project: WildFly > Issue Type: Sub-task > Components: Domain Management > Reporter: Stuart Douglas > Assignee: Brian Stansberry > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 16:39:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 5 Nov 2014 16:39:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3793) Implement transformers for graceful shutdown operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFLY-3793: ----------------------------------- Parent: (was: WFLY-1247) Issue Type: Task (was: Sub-task) > Implement transformers for graceful shutdown operations > ------------------------------------------------------- > > Key: WFLY-3793 > URL: https://issues.jboss.org/browse/WFLY-3793 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Stuart Douglas > Assignee: Brian Stansberry > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 16:39:31 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 5 Nov 2014 16:39:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-219) Implement transformers for graceful shutdown operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved WFLY-3793 to WFCORE-219: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-219 (was: WFLY-3793) Component/s: Domain Management (was: Domain Management) > Implement transformers for graceful shutdown operations > ------------------------------------------------------- > > Key: WFCORE-219 > URL: https://issues.jboss.org/browse/WFCORE-219 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Stuart Douglas > Assignee: Brian Stansberry > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 16:40:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 5 Nov 2014 16:40:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-219) Implement transformers for graceful shutdown operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017654#comment-13017654 ] Brian Stansberry commented on WFCORE-219: ----------------------------------------- The /host=xxx ones don't need transformation, as they are targeted at a particular host. > Implement transformers for graceful shutdown operations > ------------------------------------------------------- > > Key: WFCORE-219 > URL: https://issues.jboss.org/browse/WFCORE-219 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Stuart Douglas > Assignee: Brian Stansberry > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 16:42:29 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 5 Nov 2014 16:42:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-219) Implement transformers for graceful shutdown operations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017651#comment-13017651 ] Stuart Douglas edited comment on WFCORE-219 at 11/5/14 4:41 PM: ---------------------------------------------------------------- Ops are: :resume-servers() (new op) :suspend-servers(timeout=?) (new op) /server-group=main-server-group:suspend-servers(timeout=?) (new op) /server-group=main-server-group:resume-servers() (new op) :stop-servers(blocking=true, timeout=?) (new timeout attribute) /server-group=main-server-group:stop-servers(blocking=true, timeout=?) (new timeout attribute) was (Author: swd847): Ops are: :resume-servers() (new op) :suspend-servers(timeout=?) (new op) /server-group=main-server-group:suspend-servers(timeout=?) (new op) /server-group=main-server-group:resume-servers() (new op) /host=master/server-config=server-one:suspend(timeout=?) (new op) /host=master/server-config=server-one:resume(timeout=?) (new op) :stop-servers(blocking=true, timeout=?) (new timeout attribute) /server-group=main-server-group:stop-servers(blocking=true, timeout=?) (new timeout attribute) /host=master/server-config=server-one:stop(timeout=?) (new timeout attribute) > Implement transformers for graceful shutdown operations > ------------------------------------------------------- > > Key: WFCORE-219 > URL: https://issues.jboss.org/browse/WFCORE-219 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Stuart Douglas > Assignee: Brian Stansberry > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 16:45:30 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 5 Nov 2014 16:45:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4056) Graceful shutdown for JMS In-Reply-To: References: Message-ID: Stuart Douglas created WFLY-4056: ------------------------------------ Summary: Graceful shutdown for JMS Key: WFLY-4056 URL: https://issues.jboss.org/browse/WFLY-4056 Project: WildFly Issue Type: Sub-task Components: JMS Reporter: Stuart Douglas Assignee: Jeff Mesnil -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 16:46:29 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 5 Nov 2014 16:46:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4056) Graceful shutdown for JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017655#comment-13017655 ] Stuart Douglas commented on WFLY-4056: -------------------------------------- I *think* what is required here is for the server to stop accepting messages from remote connectors. I think local messages should still be accepted, JMS may be used by local components such as EJB's. Some kind of cluster failover may also be required? > Graceful shutdown for JMS > ------------------------- > > Key: WFLY-4056 > URL: https://issues.jboss.org/browse/WFLY-4056 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Stuart Douglas > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 16:55:30 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 5 Nov 2014 16:55:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3772) Implement graceful shutdown for JCA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017657#comment-13017657 ] Stuart Douglas commented on WFLY-3772: -------------------------------------- I think no work is actually required here, as the only JCA related endpoint is MDB delivery, which is covered in the EJB subsystem. > Implement graceful shutdown for JCA > ----------------------------------- > > Key: WFLY-3772 > URL: https://issues.jboss.org/browse/WFLY-3772 > Project: WildFly > Issue Type: Sub-task > Components: JCA > Reporter: Stuart Douglas > Assignee: Stefano Maestri > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 17:12:29 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 5 Nov 2014 17:12:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3765) Runtime modifications in static files of exploded WARs of exploded EARs aren't reflected. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-3765: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/6913 > Runtime modifications in static files of exploded WARs of exploded EARs aren't reflected. > ----------------------------------------------------------------------------------------- > > Key: WFLY-3765 > URL: https://issues.jboss.org/browse/WFLY-3765 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: OS: Xubuntu 14.04 64-bit (Linux) > JDK: 1.8.0 Update 20 > Reporter: Avor Nadal > Assignee: Stuart Douglas > Labels: deployment, exploded, undertow > Fix For: 9.0.0.Alpha1 > > > If you put a exploded WAR in $WILDFLY/standalone/deployments/ and modify a static file once the application is deployed and running, such as an HTML or JPEG file, the changes are reflected in the output to the client. However, if the exploded WAR is contained at the same time in a exploded EAR, they aren't. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 19:25:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 5 Nov 2014 19:25:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3446) cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins reassigned WFLY-3446: ----------------------------------- Assignee: James Perkins (was: Tomaz Cerar) > cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored > ---------------------------------------------------------------------- > > Key: WFLY-3446 > URL: https://issues.jboss.org/browse/WFLY-3446 > Project: WildFly > Issue Type: Bug > Components: CLI, Scripts > Affects Versions: 8.1.0.Final > Reporter: Alexey Loubyansky > Assignee: James Perkins > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > E.g. ./jboss-cli.sh -Djboss.cli.config=/jboss-cli.xml > The system property won't be set, instead the argument will treated as simply a command line argument. > This has to be fixed in the scripts themselves launching the CLI. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 19:33:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 5 Nov 2014 19:33:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-220) cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins moved WFLY-3446 to WFCORE-220: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-220 (was: WFLY-3446) Affects Version/s: (was: 8.1.0.Final) Component/s: CLI Scripts (was: CLI) (was: Scripts) Fix Version/s: (was: 9.0.0.Beta1) (was: 8.2.0.CR1) > cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored > ---------------------------------------------------------------------- > > Key: WFCORE-220 > URL: https://issues.jboss.org/browse/WFCORE-220 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Scripts > Reporter: Alexey Loubyansky > Assignee: James Perkins > > E.g. ./jboss-cli.sh -Djboss.cli.config=/jboss-cli.xml > The system property won't be set, instead the argument will treated as simply a command line argument. > This has to be fixed in the scripts themselves launching the CLI. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 20:31:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 5 Nov 2014 20:31:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-220) cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017664#comment-13017664 ] RH Bugzilla Integration commented on WFCORE-220: ------------------------------------------------ James Perkins changed the Status of [bug 1103620|https://bugzilla.redhat.com/show_bug.cgi?id=1103620] from ASSIGNED to POST > cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored > ---------------------------------------------------------------------- > > Key: WFCORE-220 > URL: https://issues.jboss.org/browse/WFCORE-220 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Scripts > Reporter: Alexey Loubyansky > Assignee: James Perkins > > E.g. ./jboss-cli.sh -Djboss.cli.config=/jboss-cli.xml > The system property won't be set, instead the argument will treated as simply a command line argument. > This has to be fixed in the scripts themselves launching the CLI. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 22:04:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 5 Nov 2014 22:04:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-221) Scanner deployments are getting persisted to standalone.xml In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-221: --------------------------------------- Summary: Scanner deployments are getting persisted to standalone.xml Key: WFCORE-221 URL: https://issues.jboss.org/browse/WFCORE-221 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha11 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 1.0.0.Alpha12 Shouldn't happen. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 5 23:48:30 2014 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Wed, 5 Nov 2014 23:48:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4057) jboss-cli.bat stops working In-Reply-To: References: Message-ID: Juergen Zimmermann created WFLY-4057: ---------------------------------------- Summary: jboss-cli.bat stops working Key: WFLY-4057 URL: https://issues.jboss.org/browse/WFLY-4057 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: 9.0.0.Beta1 Reporter: Juergen Zimmermann Assignee: Alexey Loubyansky I compiled the latest snapshot for 9.0.0.Alpha2. However, jboss-cli.bat doesn't work anymore. When I compiled the snapshot last week (Wed. 10/30/14 ?) jboss-cli.bat was working fine. Here is an example for the broken jboss-cli.bat: {code} jboss-cli.bat -c --command=:shutdown ':shutdown' is assumed to be a command(s) but the commands to execute have been specified by another argument: [--command] {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 01:46:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 01:46:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-165) Server jvm settings take effect only after host controller restart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017698#comment-13017698 ] RH Bugzilla Integration commented on WFCORE-165: ------------------------------------------------ Petr Kremensky changed the Status of [bug 990274|https://bugzilla.redhat.com/show_bug.cgi?id=990274] from ON_QA to VERIFIED > Server jvm settings take effect only after host controller restart > ------------------------------------------------------------------- > > Key: WFCORE-165 > URL: https://issues.jboss.org/browse/WFCORE-165 > Project: WildFly Core > Issue Type: Feature Request > Affects Versions: 1.0.0.Alpha9 > Reporter: Kabir Khan > Assignee: Kabir Khan > Fix For: 1.0.0.Alpha11 > > > If you start a domain/host with one server, and that server has e.g. a too small heap: > {code} > > > > > > > > > {code} > The server will fail on boot: > {code} > [Server:server-one] Error occurred during initialization of VM > [Server:server-one] Too small initial heap > {code} > Trying to call > {code} > /host=master/server-config=server-one/jvm=default:write-attribute(name=heap-size,value=64m) > /host=master/server-config=server-one:start > {code} > results in the same error. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 02:27:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 02:27:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-205) ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017700#comment-13017700 ] RH Bugzilla Integration commented on WFCORE-205: ------------------------------------------------ Marek Kopecky changed the Status of [bug 1078062|https://bugzilla.redhat.com/show_bug.cgi?id=1078062] from ON_QA to VERIFIED > ManagedDMRContentTypeResource does not use a map with consistent ordering for storing content > --------------------------------------------------------------------------------------------- > > Key: WFCORE-205 > URL: https://issues.jboss.org/browse/WFCORE-205 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha11 > > > ManagedDMRContentTypeResource.content is used for generating an overall hash for the stored content, but it does not use consistent ordering (i.e. it needs to be a LinkedHashMap or perhaps a TreeMap.) The result is when another node in the domain receives an update it may calculate a different overall hash. > This is surfacing as failures in https://bugzilla.redhat.com/show_bug.cgi?id=1078062 when the master and slave are running on different JVM releases. Different VM releases often have different ordering behavior when iterating over the unordered collections. > I believe this is unlikely to result in real-world problems since any backup will persist its own version of the hash to its local copy of domain.xml, so there won't be any mismatch. The importance of the overall hash is that it allows the process to find the content in the repo when it is added. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 03:51:29 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 6 Nov 2014 03:51:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4058) Upgrade HAL to 2.4.6.Final In-Reply-To: References: Message-ID: Harald Pehl created WFLY-4058: --------------------------------- Summary: Upgrade HAL to 2.4.6.Final Key: WFLY-4058 URL: https://issues.jboss.org/browse/WFLY-4058 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 03:51:30 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 6 Nov 2014 03:51:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4059) Upgrade HAL to 2.4.6.Final In-Reply-To: References: Message-ID: Harald Pehl created WFLY-4059: --------------------------------- Summary: Upgrade HAL to 2.4.6.Final Key: WFLY-4059 URL: https://issues.jboss.org/browse/WFLY-4059 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 8.2.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 03:51:30 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 6 Nov 2014 03:51:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4058) Upgrade HAL to 2.4.6.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4058: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6830) > Upgrade HAL to 2.4.6.Final > -------------------------- > > Key: WFLY-4058 > URL: https://issues.jboss.org/browse/WFLY-4058 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 03:51:30 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 6 Nov 2014 03:51:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4059) Upgrade HAL to 2.4.6.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4059: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6831) > Upgrade HAL to 2.4.6.Final > -------------------------- > > Key: WFLY-4059 > URL: https://issues.jboss.org/browse/WFLY-4059 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 05:21:30 2014 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Thu, 6 Nov 2014 05:21:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3262) WebServiceRef injection without explicit wsdl file fails during Servlet initialization In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated WFLY-3262: ---------------------------------- Fix Version/s: (was: 9.0.0.CR1) > WebServiceRef injection without explicit wsdl file fails during Servlet initialization > -------------------------------------------------------------------------------------- > > Key: WFLY-3262 > URL: https://issues.jboss.org/browse/WFLY-3262 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.CR1 > Reporter: Matus Abaffy > Assignee: R Searls > > Reproducer test available at https://github.com/bafco/wildfly/commits/wsServletInjection > I have the following servlet > {code} > @WebServlet(/*..., */ loadOnStartup = 1) > public class ServletLoadOnStartup extends HttpServlet { > @WebServiceRef(value = EndpointService.class) > private EndpointInterface endpoint1; > //... > {code} > (It is located in the package org.jboss.as.test.integration.ws.serviceref. There you can find more info about the other classes.) > And i get the following exception: > {code} > org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: ws-servlet-test.war > ... > Caused by: java.lang.Exception: {"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./ws-servlet-test" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ws-servlet-test: javax.servlet.ServletException: UT010013: Could not instantiate ServletLoadOnStartup > Caused by: javax.servlet.ServletException: UT010013: Could not instantiate ServletLoadOnStartup > Caused by: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance > Caused by: java.lang.RuntimeException: JBAS011875: Resource lookup for injection failed: env/org.jboss.as.test.integration.ws.serviceref.ServletLoadOnStartup/endpoint1 > Caused by: javax.naming.NamingException: JBAS011878: Failed to lookup env/org.jboss.as.test.integration.ws.serviceref.ServletLoadOnStartup/endpoint1 [Root exception is org.jboss.wsf.spi.WSFException: Cannot create service] > Caused by: org.jboss.wsf.spi.WSFException: Cannot create service > Caused by: java.lang.reflect.InvocationTargetException > Caused by: javax.xml.ws.WebServiceException: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service. > Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service. > Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: Problem parsing 'http://localhost:8080/ws-servlet-test/EndpointService/EJB3Bean?wsdl'.: java.io.FileNotFoundException: http://localhost:8080/ws-servlet-test/EndpointService/EJB3Bean?wsdl > Caused by: java.io.FileNotFoundException: http://localhost:8080/ws-servlet-test/EndpointService/EJB3Bean?wsdl"}} > {code} > If I change loadOnStartup parameter to -1, everything works fine, i.e. servlet gets instantiated and WS is injected correctly. Therefore, I suppose this is a bug. > Another workaround exists - adding wsdl file to the deployment archive and using the 'wsdlLocation' parameter in @WebServiceRef (as can be seen in ServiceRefSevletTestCase). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 05:38:30 2014 From: issues at jboss.org (Harald Wellmann (JIRA)) Date: Thu, 6 Nov 2014 05:38:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4027) RESTEasy ViolationReport is not processed by JAXB provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Wellmann reopened WFLY-4027: ----------------------------------- It seems the current solution is only partial. I now do get a marshalled {{ViolationReport}}, but the content is incomplete: {code:xml} {code} {{}} should not be empty. The problem is that {{parameterViolations}} is a list of {{ResteasyConstraintViolation}}. This class has getters but no setters, which should be ok for JAXB since the class is annotated with {{@XmlAccessorType(XmlAccessType.FIELD)}}. However, the class {{ResteasyConstraintViolation}} is loaded from the module {{org.jboss.resteasy.resteasy-jaxrs}} which does not import {{javax.xml.bind.api}}, so the JAXB marshaller does not detect the {{XmlAccessorType}} annotation since the annotation class was loaded from the wrong class loader. After adding {code:xml} {code} to the {{org.jboss.resteasy.resteasy-jaxrs}} module, I now do get the correct validation message. Not knowing too much about RESTeasy and WildFly internals, I'm not fully confident that this is now the final solution - it might be helpful to add a couple of regression tests for marshalled violation reports with different combinations of violations. > RESTEasy ViolationReport is not processed by JAXB provider > ---------------------------------------------------------- > > Key: WFLY-4027 > URL: https://issues.jboss.org/browse/WFLY-4027 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 8.1.0.Final, 8.2.0.CR1, 9.0.0.Alpha1 > Reporter: Harald Wellmann > Assignee: Stuart Douglas > Labels: resteasy, validation > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > When used in combination with Bean Validation, RESTEasy should wrap validation errors in a {{ValidationReport}} which should be included in the REST response, marshalled to JSON or XML, depending on the content type. > This does not work currently in WildFly 8.1.0.Final. > The issue was reported in RESTEASY-1054. and is marked as fixed in RESTEasy 3.0.9.Final. > However, I can still reproduce the issue with a local build of WildFly 8.2.0.CR1-SNAPSHOT (from the 8.x branch) which includes RESTEasy 3.0.10.Final. > Going back to WildFly 8.1.0.Final, the issue no longer occurs when I add > {code} > > {code} > to the {{module.xml}} descriptor of {{org.jboss.resteasy.resteasy-validator-provider-11}}. > The same fix works for 8.2.0.CR1-SNAPSHOT. > Looking at the module descriptor, it seems that 9.0.0.Alpha1 is also affected (but I did not test my sample on 9.0.0.Alpha1). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 05:39:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 05:39:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-57) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017746#comment-13017746 ] RH Bugzilla Integration commented on WFCORE-57: ----------------------------------------------- Emmanuel Hugonnet (ehsavoie) changed the Status of [bug 1070214|https://bugzilla.redhat.com/show_bug.cgi?id=1070214] from NEW to POST > Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* > -------------------------------------------------------------------------------- > > Key: WFCORE-57 > URL: https://issues.jboss.org/browse/WFCORE-57 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Harald Pehl > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > When executing > {code} > /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2) > {code} > the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}: > {code} > ... > "acl" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > "model-description" => {"classic" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > ... > "operations" => undefined, > "children" => { > "acl-module" => { > "description" => "ACL module", > "model-description" => {"*" => { > "description" => "List of authentication modules", > ... > "operations" => undefined, > "children" => {} > }} > }, > "login-module" => { > "description" => "Login module", > "model-description" => {"*" => undefined} > } > } > }} > }, > ... > {code} > However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 06:00:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 06:00:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3942) Race condition with clean shutdown and mod_cluster session draining In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-3942: ------------------------------------------ Bugzilla Update: Perform > Race condition with clean shutdown and mod_cluster session draining > ------------------------------------------------------------------- > > Key: WFLY-3942 > URL: https://issues.jboss.org/browse/WFLY-3942 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > Probably same issue exists in WF as well, I will revalidate the logic for race conditions. > https://issues.jboss.org/browse/MODCLUSTER-399 > https://bugzilla.redhat.com/show_bug.cgi?id=1083563 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 06:05:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 06:05:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2210) fix message endpoint isDeliveryTransacted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017761#comment-13017761 ] RH Bugzilla Integration commented on WFLY-2210: ----------------------------------------------- Panagiotis Sotiropoulos changed the Status of [bug 1161078|https://bugzilla.redhat.com/show_bug.cgi?id=1161078] from NEW to ASSIGNED > fix message endpoint isDeliveryTransacted > ----------------------------------------- > > Key: WFLY-2210 > URL: https://issues.jboss.org/browse/WFLY-2210 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Alpha4 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 8.0.0.CR1 > > > The org.jboss.as.ejb3.inflow.MessageEndpointService#isDeliveryTransacted method is checking the transaction attribute of the method using the MethodIntf.BEAN while it should use the MethodIntf.MESSAGE_ENDPOINT type. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 06:06:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 06:06:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3942) Race condition with clean shutdown and mod_cluster session draining In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017762#comment-13017762 ] RH Bugzilla Integration commented on WFLY-3942: ----------------------------------------------- Panagiotis Sotiropoulos changed the Status of [bug 1161079|https://bugzilla.redhat.com/show_bug.cgi?id=1161079] from NEW to ASSIGNED > Race condition with clean shutdown and mod_cluster session draining > ------------------------------------------------------------------- > > Key: WFLY-3942 > URL: https://issues.jboss.org/browse/WFLY-3942 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > Probably same issue exists in WF as well, I will revalidate the logic for race conditions. > https://issues.jboss.org/browse/MODCLUSTER-399 > https://bugzilla.redhat.com/show_bug.cgi?id=1083563 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 06:23:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 06:23:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2210) fix message endpoint isDeliveryTransacted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017769#comment-13017769 ] RH Bugzilla Integration commented on WFLY-2210: ----------------------------------------------- Panagiotis Sotiropoulos changed the Status of [bug 1161078|https://bugzilla.redhat.com/show_bug.cgi?id=1161078] from ASSIGNED to POST > fix message endpoint isDeliveryTransacted > ----------------------------------------- > > Key: WFLY-2210 > URL: https://issues.jboss.org/browse/WFLY-2210 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Alpha4 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 8.0.0.CR1 > > > The org.jboss.as.ejb3.inflow.MessageEndpointService#isDeliveryTransacted method is checking the transaction attribute of the method using the MethodIntf.BEAN while it should use the MethodIntf.MESSAGE_ENDPOINT type. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 06:27:32 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 06:27:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3942) Race condition with clean shutdown and mod_cluster session draining In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017770#comment-13017770 ] RH Bugzilla Integration commented on WFLY-3942: ----------------------------------------------- Panagiotis Sotiropoulos changed the Status of [bug 1161079|https://bugzilla.redhat.com/show_bug.cgi?id=1161079] from ASSIGNED to POST > Race condition with clean shutdown and mod_cluster session draining > ------------------------------------------------------------------- > > Key: WFLY-3942 > URL: https://issues.jboss.org/browse/WFLY-3942 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > Probably same issue exists in WF as well, I will revalidate the logic for race conditions. > https://issues.jboss.org/browse/MODCLUSTER-399 > https://bugzilla.redhat.com/show_bug.cgi?id=1083563 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 06:49:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 06:49:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3995) Add tests for suffix option on size-rotating-file-handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017777#comment-13017777 ] RH Bugzilla Integration commented on WFLY-3995: ----------------------------------------------- Petr Kremensky changed the Status of [bug 1160541|https://bugzilla.redhat.com/show_bug.cgi?id=1160541] from NEW to POST > Add tests for suffix option on size-rotating-file-handler > --------------------------------------------------------- > > Key: WFLY-3995 > URL: https://issues.jboss.org/browse/WFLY-3995 > Project: WildFly > Issue Type: Enhancement > Reporter: Petr Kremensky > Assignee: Petr Kremensky > > Add tests for WFCORE-113 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 07:15:33 2014 From: issues at jboss.org (James Strachan (JIRA)) Date: Thu, 6 Nov 2014 07:15:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3509) git backend for loading/storing the configuration XML for wildfly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017786#comment-13017786 ] James Strachan commented on WFLY-3509: -------------------------------------- being able to inject the remote git repo & branch to use via environment variables would rock; then folks could spin up lots of docker images and they could all share the same underlying configuration > git backend for loading/storing the configuration XML for wildfly > ----------------------------------------------------------------- > > Key: WFLY-3509 > URL: https://issues.jboss.org/browse/WFLY-3509 > Project: WildFly > Issue Type: Feature Request > Reporter: James Strachan > Assignee: Jason Greene > Priority: Critical > > when working with wildfly in a cloud/paas environment (like openshift, fabric8, docker, heroku et al) it'd be great to have a git repository for the configuration folder so that writes work something like: > * git pull > * write the, say, standalone.xml file > * git commit -a -m "some comment" > * git push > (with a handler to deal with conflicts; such as last write wins). > Then an optional periodic 'git pull' and reload configuration if there is a change. > This would then mean that folks could use a number of wildfly containers using docker / openshift / fabric8 and then have a shared git repository (e.g. the git repo in openshift or fabric8) to configure a group of wildfly containers. Folks could then reuse the wildfly management console within cloud environments (as the management console would, under the covers, be loading/saving from/to git) > Folks could then benefit from git tooling when dealing with versioning and audit logs of changes to the XML; along with getting the benefit of branching, tagging. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 07:23:29 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Thu, 6 Nov 2014 07:23:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-222) Update domain configuration files In-Reply-To: References: Message-ID: Emmanuel Hugonnet created WFCORE-222: ---------------------------------------- Summary: Update domain configuration files Key: WFCORE-222 URL: https://issues.jboss.org/browse/WFCORE-222 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Affects Versions: 1.0.0.Alpha11 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet Priority: Minor After integration of WFCORE-75 the configuration files for the host haven't been updated to show this new option. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 07:29:30 2014 From: issues at jboss.org (=?UTF-8?Q?Jacob_Ils=C3=B8_=28JIRA=29?=) Date: Thu, 6 Nov 2014 07:29:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3765) Runtime modifications in static files of exploded WARs of exploded EARs aren't reflected. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017794#comment-13017794 ] Jacob Ils? commented on WFLY-3765: ---------------------------------- Thanks for the pull request. Will try it out. > Runtime modifications in static files of exploded WARs of exploded EARs aren't reflected. > ----------------------------------------------------------------------------------------- > > Key: WFLY-3765 > URL: https://issues.jboss.org/browse/WFLY-3765 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: OS: Xubuntu 14.04 64-bit (Linux) > JDK: 1.8.0 Update 20 > Reporter: Avor Nadal > Assignee: Stuart Douglas > Labels: deployment, exploded, undertow > Fix For: 9.0.0.Alpha1 > > > If you put a exploded WAR in $WILDFLY/standalone/deployments/ and modify a static file once the application is deployed and running, such as an HTML or JPEG file, the changes are reflected in the output to the client. However, if the exploded WAR is contained at the same time in a exploded EAR, they aren't. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 08:06:30 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Thu, 6 Nov 2014 08:06:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3772) Implement graceful shutdown for JCA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesper Pedersen closed WFLY-3772. --------------------------------- Resolution: Deferred > Implement graceful shutdown for JCA > ----------------------------------- > > Key: WFLY-3772 > URL: https://issues.jboss.org/browse/WFLY-3772 > Project: WildFly > Issue Type: Sub-task > Components: JCA > Reporter: Stuart Douglas > Assignee: Stefano Maestri > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 08:50:30 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Thu, 6 Nov 2014 08:50:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1232) IronJacamar 1.1.9.Final In-Reply-To: References: Message-ID: Jesper Pedersen created JBJCA-1232: -------------------------------------- Summary: IronJacamar 1.1.9.Final Key: JBJCA-1232 URL: https://issues.jboss.org/browse/JBJCA-1232 Project: IronJacamar Issue Type: Release Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.1.9.Final Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12325756 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 08:55:32 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Thu, 6 Nov 2014 08:55:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1232) IronJacamar 1.1.9.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesper Pedersen resolved JBJCA-1232. ------------------------------------ Resolution: Done > IronJacamar 1.1.9.Final > ----------------------- > > Key: JBJCA-1232 > URL: https://issues.jboss.org/browse/JBJCA-1232 > Project: IronJacamar > Issue Type: Release > Components: Build > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.1.9.Final > > > Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12325756 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 09:05:30 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Thu, 6 Nov 2014 09:05:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3256) IronJacamar 1.1.8.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesper Pedersen reopened WFLY-3256: ----------------------------------- > IronJacamar 1.1.8.Final > ----------------------- > > Key: WFLY-3256 > URL: https://issues.jboss.org/browse/WFLY-3256 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 09:05:31 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Thu, 6 Nov 2014 09:05:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3256) IronJacamar 1.1.9.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesper Pedersen updated WFLY-3256: ---------------------------------- Summary: IronJacamar 1.1.9.Final (was: IronJacamar 1.1.8.Final) > IronJacamar 1.1.9.Final > ----------------------- > > Key: WFLY-3256 > URL: https://issues.jboss.org/browse/WFLY-3256 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 09:27:32 2014 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Thu, 6 Nov 2014 09:27:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called before all persistence units have performed database updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Marlow updated WFLY-3619: ------------------------------- Forum Reference: https://community.jboss.org/message/880815#880815, https://developer.jboss.org/thread/248287, https://developer.jboss.org/message/799730#799730 (was: https://community.jboss.org/message/880815#880815, https://developer.jboss.org/thread/248287) > XA END / un-enlist for database connection called before all persistence units have performed database updates > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3619 > URL: https://issues.jboss.org/browse/WFLY-3619 > Project: WildFly > Issue Type: Bug > Components: EJB, JCA, JPA / Hibernate, Transactions > Affects Versions: 8.0.0.Final > Environment: Windows 7 64-bit > JDK 1.8.0_05-b13 64-Bit > MS SQL Server 2012 database > Latest MS JDBC driver > XA datasource > Reporter: Andreas Liebscher > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > Attachments: persistence.xml, server-9.0.0.Alpha1-SNAPHOT-trace.log, server-9.0.0.Alpha1-SNAPHOT.log, server-all-traces-full.log.gz, server-org-jboss-as-jpa.log, server.jca.log, server_MSSQL_Trace.log > > > While trying to port an EE application from JBoss5 to WF8 the following problem occurred: > EJBs (@Required) using JPA to do some data changes. > Some changes get already written to the database, others reside in the session cache. > After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion. > Then more changes are flushed to the database, but I run in a reproduceable database locking problem. > After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call. > There should be exactly one xa transaction active processing all data changes. > But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction. > After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour: > - a connection is enlisted and xa start called > - the same connection is used for several select / insert / update statements > - after return of the top EJB call on the same connection xa end and connection un-enlist is called > - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected. > Shouldn't xa end be called AFTER beforeCompletion / session flush!?! -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 09:29:32 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 09:29:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3789) Vault cannot be initialized with external password provided by CLASS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017921#comment-13017921 ] RH Bugzilla Integration commented on WFLY-3789: ----------------------------------------------- Peter Skopek changed the Status of [bug 1146006|https://bugzilla.redhat.com/show_bug.cgi?id=1146006] from NEW to POST > Vault cannot be initialized with external password provided by CLASS > --------------------------------------------------------------------- > > Key: WFLY-3789 > URL: https://issues.jboss.org/browse/WFLY-3789 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Filip Bogyai > Assignee: Peter Skopek > > When vault is configured to use external password obtained from CLASS, e.g. :{code:xml} {code} > WildFly is unable to start, because of ClassNotFoundException: > {code} > 11:00:40,696 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("core-service" => "vault")]): java.lang.RuntimeException: WFLYSRV0076: Error initializing vault -- org.jboss.as.server.services.security.VaultReaderException: WFLYSEC0017: Vault Reader Exception: > at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:88) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:657) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:498) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:299) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:294) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1072) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:375) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:297) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.server.ServerService.boot(ServerService.java:373) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.server.ServerService.boot(ServerService.java:348) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:259) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > Caused by: org.jboss.as.server.services.security.VaultReaderException: WFLYSEC0017: Vault Reader Exception: > at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:99) [wildfly-security-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:86) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > ... 12 more > Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.ClassNotFoundException: org.jboss.security.plugins.TmpFilePassword from [Module "org.jboss.as.controller:main" from local module loader @4be525ab > at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:97) [wildfly-security-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > ... 13 more > Caused by: java.lang.ClassNotFoundException: org.jboss.security.plugins.TmpFilePassword from [Module "org.jboss.as.controller:main" from local module loader @4be525ab > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final] > at org.jboss.security.Util.invokePasswordClass(Util.java:174) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.jboss.security.Util.loadPassword(Util.java:126) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.picketbox.plugins.vault.PicketBoxSecurityVault.loadKeystorePassword(PicketBoxSecurityVault.java:343) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:204) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > ... 14 more > {code} > External passwords for vault were introduces by RFE: SECURITY-831 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 09:29:34 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 09:29:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-788) PicketBoxSecurityVault is not writing data to store after removing from map in memory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017923#comment-13017923 ] RH Bugzilla Integration commented on SECURITY-788: -------------------------------------------------- Peter Skopek changed the Status of [bug 1153614|https://bugzilla.redhat.com/show_bug.cgi?id=1153614] from NEW to POST > PicketBoxSecurityVault is not writing data to store after removing from map in memory > ------------------------------------------------------------------------------------- > > Key: SECURITY-788 > URL: https://issues.jboss.org/browse/SECURITY-788 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: PicketBox_4_0_21.Beta1 > > > PicketBoxSecurityVault is not writing data to store after removing from map in memory. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 09:35:30 2014 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Thu, 6 Nov 2014 09:35:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4060) Intermittent failures on SendMessage testcase when running with JTS In-Reply-To: References: Message-ID: Ond?ej Chaloupka created WFLY-4060: -------------------------------------- Summary: Intermittent failures on SendMessage testcase when running with JTS Key: WFLY-4060 URL: https://issues.jboss.org/browse/WFLY-4060 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Ond?ej Chaloupka Assignee: Ond?ej Chaloupka During testing EAP I was hitting intermittent failures on SendMessageTestscase which was caused by timing issues. There is a bit more explanation of reasons at bz: https://bugzilla.redhat.com/show_bug.cgi?id=1160761 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 09:36:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 09:36:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4060) Intermittent failures on SendMessage testcase when running with JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4060: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1160761 > Intermittent failures on SendMessage testcase when running with JTS > ------------------------------------------------------------------- > > Key: WFLY-4060 > URL: https://issues.jboss.org/browse/WFLY-4060 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ond?ej Chaloupka > Assignee: Ond?ej Chaloupka > > During testing EAP I was hitting intermittent failures on SendMessageTestscase which was caused by timing issues. > There is a bit more explanation of reasons at bz: https://bugzilla.redhat.com/show_bug.cgi?id=1160761 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 09:39:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 09:39:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017930#comment-13017930 ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Darran Lofthouse changed the Status of [bug 1149618|https://bugzilla.redhat.com/show_bug.cgi?id=1149618] from NEW to ASSIGNED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 10:06:29 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 6 Nov 2014 10:06:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-216) Add ModelValidator to ensure resource model is correct In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFCORE-216: ------------------------------- Summary: Add ModelValidator to ensure resource model is correct (was: requires are completely ignore in AttributeDefinition when attribute is validated) > Add ModelValidator to ensure resource model is correct > ------------------------------------------------------ > > Key: WFCORE-216 > URL: https://issues.jboss.org/browse/WFCORE-216 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stefano Maestri > Assignee: Tomaz Cerar > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 10:07:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 6 Nov 2014 10:07:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-216) Add ModelValidator to ensure resource model is correct In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFCORE-216: ------------------------------- Description: Currently there is no validation of "requires" and "alternatives" that are specified in attribute metadata / AttributeDefinition ModelValidator should be added as extra step handler that executes on end of MODEL phase to ensure resource model is correct. > Add ModelValidator to ensure resource model is correct > ------------------------------------------------------ > > Key: WFCORE-216 > URL: https://issues.jboss.org/browse/WFCORE-216 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stefano Maestri > Assignee: Tomaz Cerar > > Currently there is no validation of "requires" and "alternatives" that are specified in attribute metadata / AttributeDefinition > ModelValidator should be added as extra step handler that executes on end of MODEL phase to ensure resource model is correct. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 10:15:32 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 6 Nov 2014 10:15:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-545) Alllow non persistent configuration(runtime) changes for server groups and domain using CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFLY-545: ---------------------------------- Labels: EAP (was: ) > Alllow non persistent configuration(runtime) changes for server groups and domain using CLI > ------------------------------------------------------------------------------------------- > > Key: WFLY-545 > URL: https://issues.jboss.org/browse/WFLY-545 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Shay Matasaro > Assignee: Brian Stansberry > Labels: EAP > Fix For: 9.0.0.Beta1 > > > Using the CLI , It is currently not possible to make runtime config changes to multiple servers , unless you are using a roll-out plan > One example is the ability to disable a mod-cluster context on multiple servers at once. > Since this operation does not affect the persistent server config it is currently not supported. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 10:22:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 10:22:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-764) Enhance the security realm plug-in mechanism for client-cert / external verification. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017949#comment-13017949 ] RH Bugzilla Integration commented on WFLY-764: ---------------------------------------------- Darran Lofthouse changed the Status of [bug 953200|https://bugzilla.redhat.com/show_bug.cgi?id=953200] from ASSIGNED to POST > Enhance the security realm plug-in mechanism for client-cert / external verification. > ------------------------------------------------------------------------------------- > > Key: WFLY-764 > URL: https://issues.jboss.org/browse/WFLY-764 > Project: WildFly > Issue Type: Task > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Labels: Realm_Management > Fix For: Awaiting Volunteers > > > Currently verification is just based on the defined trust store - this is to take it one step further and allow an optional additional verification. > As a first step will need to ensure we have a suitable Callback from the authenticator to the realm to verify the identity and then this can be passed on to the plug-in. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 10:22:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 10:22:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3580) Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017950#comment-13017950 ] RH Bugzilla Integration commented on WFLY-3580: ----------------------------------------------- Darran Lofthouse changed the Status of [bug 953200|https://bugzilla.redhat.com/show_bug.cgi?id=953200] from ASSIGNED to POST > Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3580 > URL: https://issues.jboss.org/browse/WFLY-3580 > Project: WildFly > Issue Type: Bug > Components: Domain Management, EJB > Reporter: Derek Horton > Assignee: Darran Lofthouse > > EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection. This makes it impossible to get the certificate for use in a custom login module. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 10:22:32 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 10:22:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017953#comment-13017953 ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Darran Lofthouse changed the Status of [bug 1149618|https://bugzilla.redhat.com/show_bug.cgi?id=1149618] from ASSIGNED to POST > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 10:48:30 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 6 Nov 2014 10:48:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3772) Implement graceful shutdown for JCA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017966#comment-13017966 ] David Lloyd commented on WFLY-3772: ----------------------------------- Wouldn't an EIS count? E.g. transaction inflow, and whatever non-EJB magic an EIS can do... > Implement graceful shutdown for JCA > ----------------------------------- > > Key: WFLY-3772 > URL: https://issues.jboss.org/browse/WFLY-3772 > Project: WildFly > Issue Type: Sub-task > Components: JCA > Reporter: Stuart Douglas > Assignee: Stefano Maestri > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 11:12:30 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 6 Nov 2014 11:12:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1900) Programmatic channel creation ignores system properties for protocol attrs In-Reply-To: References: Message-ID: Bela Ban created JGRP-1900: ------------------------------ Summary: Programmatic channel creation ignores system properties for protocol attrs Key: JGRP-1900 URL: https://issues.jboss.org/browse/JGRP-1900 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.1 When using programmatic creation of a JChannel * Variables are not substituted, e.g. {{myvar="${my.port:10}"}} * System properties are ignored, e.g. {{-Djgroups.bind_addr=192.168.1.5}} does *not* set {{TP.bind_addr}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 11:13:29 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Thu, 6 Nov 2014 11:13:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1900) Programmatic channel creation ignores system properties for protocol attrs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-1900: --------------------------- Priority: Minor (was: Major) > Programmatic channel creation ignores system properties for protocol attrs > -------------------------------------------------------------------------- > > Key: JGRP-1900 > URL: https://issues.jboss.org/browse/JGRP-1900 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.1 > > > When using programmatic creation of a JChannel > * Variables are not substituted, e.g. {{myvar="${my.port:10}"}} > * System properties are ignored, e.g. {{-Djgroups.bind_addr=192.168.1.5}} does *not* set {{TP.bind_addr}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 11:18:30 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 6 Nov 2014 11:18:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-121) Background initialization/pooling of SecureRandom In-Reply-To: References: Message-ID: David Lloyd created ELY-121: ------------------------------- Summary: Background initialization/pooling of SecureRandom Key: ELY-121 URL: https://issues.jboss.org/browse/ELY-121 Project: WildFly Elytron Issue Type: Feature Request Components: Utils Reporter: David Lloyd Priority: Minor Provide a facility to initialize and pool SecureRandom instances in a background thread so that when things like SSLContexts are initialized, there are ready SecureRandoms. A background daemon thread which simply feeds instances into a modestly-sized BlockingQueue is probably more than adequate. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 11:22:29 2014 From: issues at jboss.org (=?UTF-8?Q?Ond=C5=99ej_Chaloupka_=28JIRA=29?=) Date: Thu, 6 Nov 2014 11:22:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4060) Intermittent failures on SendMessage testcase when running with JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ond?ej Chaloupka resolved WFLY-4060. ------------------------------------ Resolution: Done https://github.com/wildfly/wildfly/pull/6920 > Intermittent failures on SendMessage testcase when running with JTS > ------------------------------------------------------------------- > > Key: WFLY-4060 > URL: https://issues.jboss.org/browse/WFLY-4060 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ond?ej Chaloupka > Assignee: Ond?ej Chaloupka > > During testing EAP I was hitting intermittent failures on SendMessageTestscase which was caused by timing issues. > There is a bit more explanation of reasons at bz: https://bugzilla.redhat.com/show_bug.cgi?id=1160761 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 11:29:39 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Thu, 6 Nov 2014 11:29:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3772) Implement graceful shutdown for JCA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017995#comment-13017995 ] Jesper Pedersen commented on WFLY-3772: --------------------------------------- [~dmlloyd] Everything is considered an EIS from a JCA PoV. But inflow (of any kind) is done through the MessageEndpointFactory implementations, so adding graceful shutdown to those would cover this. Yes, there is access to the functionality too for outbound deployments, but really only security inflow (through static resource adapter configuration) would make sense here. As the outbound part could be used by components above (through the ConnectionManager) they were excluded from graceful - f.ex. a datasource. http://www.ironjacamar.org/doc/userguide/1.2/en-US/html/ch01.html#overview gives a quick overview, but has to be related to the JCA SPI/API for the full picture. > Implement graceful shutdown for JCA > ----------------------------------- > > Key: WFLY-3772 > URL: https://issues.jboss.org/browse/WFLY-3772 > Project: WildFly > Issue Type: Sub-task > Components: JCA > Reporter: Stuart Douglas > Assignee: Stefano Maestri > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 11:52:30 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 6 Nov 2014 11:52:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3772) Implement graceful shutdown for JCA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018006#comment-13018006 ] David Lloyd commented on WFLY-3772: ----------------------------------- OK thanks for the info. > Implement graceful shutdown for JCA > ----------------------------------- > > Key: WFLY-3772 > URL: https://issues.jboss.org/browse/WFLY-3772 > Project: WildFly > Issue Type: Sub-task > Components: JCA > Reporter: Stuart Douglas > Assignee: Stefano Maestri > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 12:32:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 6 Nov 2014 12:32:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-42) Ensure methods on CommonXml called by sub-classes are not version specific. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-42: ----------------------------------- Summary: Ensure methods on CommonXml called by sub-classes are not version specific. (was: Add a ServerXml Parser which extends CommonXml) > Ensure methods on CommonXml called by sub-classes are not version specific. > --------------------------------------------------------------------------- > > Key: WFCORE-42 > URL: https://issues.jboss.org/browse/WFCORE-42 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha12 > > > Both StandaloneXml and AppclientXml parse XML starting from the server element. > This duplication has always been problematic as AppclientXml is completely separate from the remaining domain config parsing, however with the core split this is even worse. > This change is to introduce a ServerXml that can be the common base for both StandaloneXml and AppclientXml - except in extreme cases it will then be safe to ignore AppclientXml for further schema updates. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 12:34:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 6 Nov 2014 12:34:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-223) Make the version specific methods in CommonXml private In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-223: --------------------------------------- Summary: Make the version specific methods in CommonXml private Key: WFCORE-223 URL: https://issues.jboss.org/browse/WFCORE-223 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha12 Sub classes should call the non-version specific methods. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 12:40:30 2014 From: issues at jboss.org (Frederic Allard (JIRA)) Date: Thu, 6 Nov 2014 12:40:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018030#comment-13018030 ] Frederic Allard commented on JBLOGGING-111: ------------------------------------------- I think the fix mentioned by David should be implemented, but my problem is that I want to force SLF4J without developing custom code. I want to use the LoggerProvider implemented by JBoss. But there is no way to do it right now. > LoggerProvider configured with new ServiceLoader crash > ------------------------------------------------------ > > Key: JBLOGGING-111 > URL: https://issues.jboss.org/browse/JBLOGGING-111 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Beta1 > Environment: Weblogic 10.3.2.0 > Configured in ejb jar, deployed by an ear file > Reporter: Frederic Allard > Assignee: James Perkins > > There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging. > org.jboss.logging.LoggerProviders snippet : > {code} > // Next try for a service provider > try { > final ServiceLoader loader = ServiceLoader.load(LoggerProvider.class, cl); > if (loader.iterator().hasNext()) { > return loader.iterator().next(); > } > } catch (Throwable ignore) { > // TODO consider printing the stack trace as it should only happen once > } > {code} > When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider. > {code} > java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers "" > at java.util.ServiceLoader.fail(ServiceLoader.java:207) > at java.util.ServiceLoader.access$100(ServiceLoader.java:164) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) > at java.util.ServiceLoader$1.next(ServiceLoader.java:421) > at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70) > at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32) > at org.jboss.logging.LoggerProviders.(LoggerProviders.java:29) > at org.jboss.logging.Logger.getLogger(Logger.java:2177) > at org.jboss.logging.Logger$1.run(Logger.java:2277) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228) > at org.hibernate.cfg.Configuration.(Configuration.java:176) > ... > {code} > This is caused by the fact that all JBoss providers are not public classes and are instead package classes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 12:40:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 6 Nov 2014 12:40:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-205) AttributeDefinition validateOperation should convert all expression strings to ModelType.EXPRESSION In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry closed WFLY-205. --------------------------------- Fix Version/s: (was: 9.0.0.Beta1) Resolution: Won't Fix I don't want to do this. I don't think the benefit of a better error report is worth the cost of disallowing all uses of a string that looks like an expression as the value in any attribute anyone may ever define. > AttributeDefinition validateOperation should convert all expression strings to ModelType.EXPRESSION > --------------------------------------------------------------------------------------------------- > > Key: WFLY-205 > URL: https://issues.jboss.org/browse/WFLY-205 > Project: WildFly > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > > AttributeDefinition.validateOperation currently only converts a string to an expression if the attribute supports expressions. It should convert any time it sees the syntax. This way if a STRING attribute that doesn't support expressions finds one, it will reject it instead of accepting it as a raw string. > Scheduling for 7.3 out of concern this may break things in 7.2 without time to notice/adapt. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 12:44:32 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 12:44:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018035#comment-13018035 ] RH Bugzilla Integration commented on WFCORE-160: ------------------------------------------------ James Perkins changed the Status of [bug 1145960|https://bugzilla.redhat.com/show_bug.cgi?id=1145960] from ASSIGNED to POST > Bash scripts should not attempt to expand argument properties > ------------------------------------------------------------- > > Key: WFCORE-160 > URL: https://issues.jboss.org/browse/WFCORE-160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha10 > > > Scripts that parse the command line arguments use a pattern like > {code} > while [ "$#" -gt 0 ] > do > case "$1" in > *) > CLI_OPTS="$CLI_OPTS \"$1\"" > ;; > esac > shift > done > {code} > The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 13:00:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 6 Nov 2014 13:00:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4061) AttributeDefinition validateAndSet and validateOperation should perform basic type conversions before returning In-Reply-To: References: Message-ID: Brian Stansberry created WFLY-4061: -------------------------------------- Summary: AttributeDefinition validateAndSet and validateOperation should perform basic type conversions before returning Key: WFLY-4061 URL: https://issues.jboss.org/browse/WFLY-4061 Project: WildFly Issue Type: Enhancement Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 9.0.0.Beta1 If an operation passes in something like "enabled"=>"true" instead of "enabled"=>true for an AD whose type is BOOLEAN, validateAndSet should convert to BOOLEAN before storing and validateOperation should convert to boolean before returning. Doing it for validateOperation isn't so obvious, but that method already converts strings to expressions if expression are supported, and also runs any ParameterCorrector, so the method isn't a simple read of the model, and this new behavior is consistent. The method javadoc needs to be updated anyway to better reflect what it does. I don't propose to do anything complex here; e.g. descending into complex attributes. I'm pretty sure there's already a JIRA for this but I can't find it. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 13:01:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 6 Nov 2014 13:01:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-224) AttributeDefinition validateAndSet and validateOperation should perform basic type conversions before returning In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved WFLY-4061 to WFCORE-224: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-224 (was: WFLY-4061) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: 9.0.0.Beta1) > AttributeDefinition validateAndSet and validateOperation should perform basic type conversions before returning > --------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-224 > URL: https://issues.jboss.org/browse/WFCORE-224 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > If an operation passes in something like "enabled"=>"true" instead of "enabled"=>true for an AD whose type is BOOLEAN, validateAndSet should convert to BOOLEAN before storing and validateOperation should convert to boolean before returning. > Doing it for validateOperation isn't so obvious, but that method already converts strings to expressions if expression are supported, and also runs any ParameterCorrector, so the method isn't a simple read of the model, and this new behavior is consistent. The method javadoc needs to be updated anyway to better reflect what it does. > I don't propose to do anything complex here; e.g. descending into complex attributes. > I'm pretty sure there's already a JIRA for this but I can't find it. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 13:02:29 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 6 Nov 2014 13:02:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-225) Synchronize scripts with EAP script changes In-Reply-To: References: Message-ID: James Perkins created WFCORE-225: ------------------------------------ Summary: Synchronize scripts with EAP script changes Key: WFCORE-225 URL: https://issues.jboss.org/browse/WFCORE-225 Project: WildFly Core Issue Type: Task Components: Scripts Reporter: James Perkins Assignee: James Perkins Several script changes were made in EAP and the WildFly scripts should be compared to ensure all changes have made it in. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 13:06:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 6 Nov 2014 13:06:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-224) AttributeDefinition validateAndSet and validateOperation should perform basic type conversions before returning In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-224: ------------------------------------ Fix Version/s: (was: 1.0.0.Beta1) > AttributeDefinition validateAndSet and validateOperation should perform basic type conversions before returning > --------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-224 > URL: https://issues.jboss.org/browse/WFCORE-224 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > If an operation passes in something like "enabled"=>"true" instead of "enabled"=>true for an AD whose type is BOOLEAN, validateAndSet should convert to BOOLEAN before storing and validateOperation should convert to boolean before returning. > Doing it for validateOperation isn't so obvious, but that method already converts strings to expressions if expression are supported, and also runs any ParameterCorrector, so the method isn't a simple read of the model, and this new behavior is consistent. The method javadoc needs to be updated anyway to better reflect what it does. > I don't propose to do anything complex here; e.g. descending into complex attributes. > I'm pretty sure there's already a JIRA for this but I can't find it. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 13:06:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 6 Nov 2014 13:06:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-224) AttributeDefinition validateAndSet and validateOperation should perform basic type conversions before returning In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved WFCORE-224. ------------------------------------- Resolution: Duplicate Issue No wonder I couldn't find it; it's already done! > AttributeDefinition validateAndSet and validateOperation should perform basic type conversions before returning > --------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-224 > URL: https://issues.jboss.org/browse/WFCORE-224 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > If an operation passes in something like "enabled"=>"true" instead of "enabled"=>true for an AD whose type is BOOLEAN, validateAndSet should convert to BOOLEAN before storing and validateOperation should convert to boolean before returning. > Doing it for validateOperation isn't so obvious, but that method already converts strings to expressions if expression are supported, and also runs any ParameterCorrector, so the method isn't a simple read of the model, and this new behavior is consistent. The method javadoc needs to be updated anyway to better reflect what it does. > I don't propose to do anything complex here; e.g. descending into complex attributes. > I'm pretty sure there's already a JIRA for this but I can't find it. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 13:31:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 13:31:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-57) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018045#comment-13018045 ] RH Bugzilla Integration commented on WFCORE-57: ----------------------------------------------- Kabir Khan changed the Status of [bug 1070214|https://bugzilla.redhat.com/show_bug.cgi?id=1070214] from POST to MODIFIED > Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* > -------------------------------------------------------------------------------- > > Key: WFCORE-57 > URL: https://issues.jboss.org/browse/WFCORE-57 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Harald Pehl > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > When executing > {code} > /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2) > {code} > the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}: > {code} > ... > "acl" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > "model-description" => {"classic" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > ... > "operations" => undefined, > "children" => { > "acl-module" => { > "description" => "ACL module", > "model-description" => {"*" => { > "description" => "List of authentication modules", > ... > "operations" => undefined, > "children" => {} > }} > }, > "login-module" => { > "description" => "Login module", > "model-description" => {"*" => undefined} > } > } > }} > }, > ... > {code} > However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 13:36:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 13:36:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3847) AS7BindingRegistry does not respect the SPI contract In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018049#comment-13018049 ] RH Bugzilla Integration commented on WFLY-3847: ----------------------------------------------- Kabir Khan changed the Status of [bug 1124178|https://bugzilla.redhat.com/show_bug.cgi?id=1124178] from POST to MODIFIED > AS7BindingRegistry does not respect the SPI contract > ---------------------------------------------------- > > Key: WFLY-3847 > URL: https://issues.jboss.org/browse/WFLY-3847 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > Fix For: 9.0.0.Alpha1 > > > The implementation of AS7BindingRegistry#lookup always return null. > This method is called by HornetQ when JNDI entries for its resources > are updated using its own management API. > We advise against using it in WildFly (and use WildFly own management API) but we must still respect the SPI contract for this method. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 13:37:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 6 Nov 2014 13:37:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3841) double :remove of connection-property from a DS leave it in wrong state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018050#comment-13018050 ] RH Bugzilla Integration commented on WFLY-3841: ----------------------------------------------- Kabir Khan changed the Status of [bug 1024239|https://bugzilla.redhat.com/show_bug.cgi?id=1024239] from POST to MODIFIED > double :remove of connection-property from a DS leave it in wrong state > ----------------------------------------------------------------------- > > Key: WFLY-3841 > URL: https://issues.jboss.org/browse/WFLY-3841 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Priority: Critical > Fix For: 9.0.0.CR1 > > > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:add(value=foo) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone at localhost:9990 /] :reload > { > "outcome" => "success", > "result" => undefined > } > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service jboss.data-source-config.ExampleDS.connection-properties.foo was depended upon by service jboss.data-source-config.ExampleDS", > "rolled-back" => true > } > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:remove > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:test-connection-in-pool > { > "outcome" => "failed", > "failure-description" => "WFLYJCA0040: failed to invoke operation: WFLYJCA0042: failed to match pool. Check JndiName: java:jboss/datasources/ExampleDS", > "rolled-back" => true > } -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 16:21:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Thu, 6 Nov 2014 16:21:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-216) Add ModelValidator to ensure resource model is correct In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFCORE-216: ------------------------------- Fix Version/s: 1.0.0.Alpha12 > Add ModelValidator to ensure resource model is correct > ------------------------------------------------------ > > Key: WFCORE-216 > URL: https://issues.jboss.org/browse/WFCORE-216 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stefano Maestri > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha12 > > > Currently there is no validation of "requires" and "alternatives" that are specified in attribute metadata / AttributeDefinition > ModelValidator should be added as extra step handler that executes on end of MODEL phase to ensure resource model is correct. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 19:47:29 2014 From: issues at jboss.org (Claudio Miranda (JIRA)) Date: Thu, 6 Nov 2014 19:47:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4062) statistics-enabled not persisted for webservices subsystem In-Reply-To: References: Message-ID: Claudio Miranda created WFLY-4062: ------------------------------------- Summary: statistics-enabled not persisted for webservices subsystem Key: WFLY-4062 URL: https://issues.jboss.org/browse/WFLY-4062 Project: WildFly Issue Type: Bug Components: Web Services Reporter: Claudio Miranda Assignee: Alessio Soldano Priority: Minor Enabling statistics for webservices subsystem is not persisted in standalone.xml/domain.xml /subsystem=webservices:write-attribute(name=statistics-enabled,value=true) It should persist as below -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 20:44:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 6 Nov 2014 20:44:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-226) DeploymentStatusHandler reads the model incorrectly In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-226: --------------------------------------- Summary: DeploymentStatusHandler reads the model incorrectly Key: WFCORE-226 URL: https://issues.jboss.org/browse/WFCORE-226 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha11 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 1.0.0.Alpha12 DeploymentStatusHandler is calling Resource.Tools.readModel() to get the mode instead of the simple Resource.getModel(). This fails because the resource is runtime-only and Resource.Tools.readModel() ignore runtime-only. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 6 22:05:30 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 6 Nov 2014 22:05:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3872) Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas resolved WFLY-3872. ---------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done This should be fixed by the last core upgrade that included a new version of Undertow > Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn > -------------------------------------------------------------------------------------------- > > Key: WFLY-3872 > URL: https://issues.jboss.org/browse/WFLY-3872 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > Since https://github.com/wildfly/wildfly/pull/6660 was submitted, EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn is failing regularly. Not every time but very often. > Alessio, you mentioned seeing some error logging from XAResourceRecoveryImpl, but that's in the logs on successful runs as well, and occurs prior to the test as well. That's a period background task from the transaction manager trying to perform recovery of some previous transaction. I don't see why it would have any impact on this test. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 00:00:32 2014 From: issues at jboss.org (Lionel Orellana (JIRA)) Date: Fri, 7 Nov 2014 00:00:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-986) JBoss Web SingleSignOn valve does not work with apps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018119#comment-13018119 ] Lionel Orellana commented on WFLY-986: -------------------------------------- The tag causes the session to be passivated and on passivation the SSO Valve removes the session from the sso entry (sessionEvent method in SingleSignOn.java line 333). With the session removed from the sso entry it doesn't get invalidated when you logout. Not sure why the session needs to be removed from the sso entry on passivation. SingleSignOne.java around line 333: if (((session.getMaxInactiveInterval() > 0) && (System.currentTimeMillis() - session.getLastAccessedTimeInternal() >= session.getMaxInactiveInterval() * 1000)) || (Session.SESSION_PASSIVATED_EVENT.equals(event.getType()))) { removeSession(ssoId, session); As far as I'm concerned removing the passivation event from this if condition would solve this problem. But I guess it is there for a reason? > JBoss Web SingleSignOn valve does not work with apps > --------------------------------------------------------------------- > > Key: WFLY-986 > URL: https://issues.jboss.org/browse/WFLY-986 > Project: WildFly > Issue Type: Bug > Reporter: Dennis Reed > Assignee: Remy Maucherat > > The JBoss Web SingleSignOn valve does not work with applications. > It incorrectly disassociates the SSO when a session is passivated. > Since this happens on every request with applications (for session replication), the SSO entry is destroyed at the end of the request. > The same issue of the SSO being removed would also happen if the session is passivated for any other reason. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 00:01:32 2014 From: issues at jboss.org (Lionel Orellana (JIRA)) Date: Fri, 7 Nov 2014 00:01:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-986) JBoss Web SingleSignOn valve does not work with apps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018119#comment-13018119 ] Lionel Orellana edited comment on WFLY-986 at 11/7/14 12:00 AM: ---------------------------------------------------------------- The tag causes the session to be passivated and on passivation the SSO Valve removes the session from the sso entry (sessionEvent method in SingleSignOn.java line 333). With the session removed from the sso entry it doesn't get invalidated when you logout. Not sure why the session needs to be removed from the sso entry on passivation. SingleSignOne.java around line 333: || if (((session.getMaxInactiveInterval() > 0) && (System.currentTimeMillis() - session.getLastAccessedTimeInternal() >= session.getMaxInactiveInterval() * 1000)) || (Session.SESSION_PASSIVATED_EVENT.equals(event.getType()))) { removeSession(ssoId, session); As far as I'm concerned removing the passivation event from this if condition would solve this problem. But I guess it is there for a reason? was (Author: lionelve): The tag causes the session to be passivated and on passivation the SSO Valve removes the session from the sso entry (sessionEvent method in SingleSignOn.java line 333). With the session removed from the sso entry it doesn't get invalidated when you logout. Not sure why the session needs to be removed from the sso entry on passivation. SingleSignOne.java around line 333: if (((session.getMaxInactiveInterval() > 0) && (System.currentTimeMillis() - session.getLastAccessedTimeInternal() >= session.getMaxInactiveInterval() * 1000)) || (Session.SESSION_PASSIVATED_EVENT.equals(event.getType()))) { removeSession(ssoId, session); As far as I'm concerned removing the passivation event from this if condition would solve this problem. But I guess it is there for a reason? > JBoss Web SingleSignOn valve does not work with apps > --------------------------------------------------------------------- > > Key: WFLY-986 > URL: https://issues.jboss.org/browse/WFLY-986 > Project: WildFly > Issue Type: Bug > Reporter: Dennis Reed > Assignee: Remy Maucherat > > The JBoss Web SingleSignOn valve does not work with applications. > It incorrectly disassociates the SSO when a session is passivated. > Since this happens on every request with applications (for session replication), the SSO entry is destroyed at the end of the request. > The same issue of the SSO being removed would also happen if the session is passivated for any other reason. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 00:01:33 2014 From: issues at jboss.org (Lionel Orellana (JIRA)) Date: Fri, 7 Nov 2014 00:01:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-986) JBoss Web SingleSignOn valve does not work with apps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018119#comment-13018119 ] Lionel Orellana edited comment on WFLY-986 at 11/7/14 12:01 AM: ---------------------------------------------------------------- The tag causes the session to be passivated and on passivation the SSO Valve removes the session from the sso entry (sessionEvent method in SingleSignOn.java line 333). With the session removed from the sso entry it doesn't get invalidated when you logout. Not sure why the session needs to be removed from the sso entry on passivation. SingleSignOne.java around line 333: || if (((session.getMaxInactiveInterval() > 0) && (System.currentTimeMillis() - session.getLastAccessedTimeInternal() >= session.getMaxInactiveInterval() * 1000)) | | (Session.SESSION_PASSIVATED_EVENT.equals(event.getType()))) { removeSession(ssoId, session); As far as I'm concerned removing the passivation event from this if condition would solve this problem. But I guess it is there for a reason? was (Author: lionelve): The tag causes the session to be passivated and on passivation the SSO Valve removes the session from the sso entry (sessionEvent method in SingleSignOn.java line 333). With the session removed from the sso entry it doesn't get invalidated when you logout. Not sure why the session needs to be removed from the sso entry on passivation. SingleSignOne.java around line 333: || if (((session.getMaxInactiveInterval() > 0) && (System.currentTimeMillis() - session.getLastAccessedTimeInternal() >= session.getMaxInactiveInterval() * 1000)) || (Session.SESSION_PASSIVATED_EVENT.equals(event.getType()))) { removeSession(ssoId, session); As far as I'm concerned removing the passivation event from this if condition would solve this problem. But I guess it is there for a reason? > JBoss Web SingleSignOn valve does not work with apps > --------------------------------------------------------------------- > > Key: WFLY-986 > URL: https://issues.jboss.org/browse/WFLY-986 > Project: WildFly > Issue Type: Bug > Reporter: Dennis Reed > Assignee: Remy Maucherat > > The JBoss Web SingleSignOn valve does not work with applications. > It incorrectly disassociates the SSO when a session is passivated. > Since this happens on every request with applications (for session replication), the SSO entry is destroyed at the end of the request. > The same issue of the SSO being removed would also happen if the session is passivated for any other reason. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 00:02:29 2014 From: issues at jboss.org (Lionel Orellana (JIRA)) Date: Fri, 7 Nov 2014 00:02:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-986) JBoss Web SingleSignOn valve does not work with apps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018119#comment-13018119 ] Lionel Orellana edited comment on WFLY-986 at 11/7/14 12:02 AM: ---------------------------------------------------------------- The tag causes the session to be passivated and on passivation the SSO Valve removes the session from the sso entry (sessionEvent method in SingleSignOn.java line 333). Not sure why the session needs to be removed from the sso entry on passivation. was (Author: lionelve): The tag causes the session to be passivated and on passivation the SSO Valve removes the session from the sso entry (sessionEvent method in SingleSignOn.java line 333). With the session removed from the sso entry it doesn't get invalidated when you logout. Not sure why the session needs to be removed from the sso entry on passivation. SingleSignOne.java around line 333: || if (((session.getMaxInactiveInterval() > 0) && (System.currentTimeMillis() - session.getLastAccessedTimeInternal() >= session.getMaxInactiveInterval() * 1000)) | | (Session.SESSION_PASSIVATED_EVENT.equals(event.getType()))) { removeSession(ssoId, session); As far as I'm concerned removing the passivation event from this if condition would solve this problem. But I guess it is there for a reason? > JBoss Web SingleSignOn valve does not work with apps > --------------------------------------------------------------------- > > Key: WFLY-986 > URL: https://issues.jboss.org/browse/WFLY-986 > Project: WildFly > Issue Type: Bug > Reporter: Dennis Reed > Assignee: Remy Maucherat > > The JBoss Web SingleSignOn valve does not work with applications. > It incorrectly disassociates the SSO when a session is passivated. > Since this happens on every request with applications (for session replication), the SSO entry is destroyed at the end of the request. > The same issue of the SSO being removed would also happen if the session is passivated for any other reason. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 02:13:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 02:13:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3905) POJO JAX-WS endpoints should not be processed if packaged in EJB-jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018122#comment-13018122 ] RH Bugzilla Integration commented on WFLY-3905: ----------------------------------------------- Jim Ma changed the Status of [bug 1147657|https://bugzilla.redhat.com/show_bug.cgi?id=1147657] from NEW to POST > POJO JAX-WS endpoints should not be processed if packaged in EJB-jar > -------------------------------------------------------------------- > > Key: WFLY-3905 > URL: https://issues.jboss.org/browse/WFLY-3905 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Kyle Lape > Assignee: Kyle Lape > Fix For: 9.0.0.Beta1 > > > If a POJO is defined like this in an EJB-jar: > {code:java} > package com.redhat.gss.ws; > @javax.jws.WebService > public class HelloService { > public String sayHello() { > return "Hello World!"; > } > } > {code} > Deployment structure: > {noformat} > klape at localhost ws-java.jar$ tree > . > ??? com > ??? ??? redhat > ??? ??? gss > ??? ??? ws > ??? ??? HelloService.java > ??? META-INF > ??? MANIFEST.MF > 5 directories, 2 files > klape at localhost ws-java.jar$ > {noformat} > Upon deployment, you get this in the log: > {noformat} > 16:52:51,372 INFO [org.jboss.ws.cxf.metadata] (MSC service thread 1-7) JBWS024061: Adding service endpoint metadata: id=com.redhat.gss.ws.HelloService > address=http://localhost:8080/ws-java/HelloService > implementor=com.redhat.gss.ws.HelloService > serviceName={http://ws.gss.redhat.com/}HelloServiceService > portName={http://ws.gss.redhat.com/}HelloServicePort > annotationWsdlLocation=null > wsdlLocationOverride=null > mtomEnabled=false > 16:52:51,571 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-7) Creating Service {http://ws.gss.redhat.com/}HelloServiceService from class com.redhat.gss.ws.HelloService > 16:52:51,879 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-7) Setting the server's publish address to be http://localhost:8080/ws-java/HelloService > 16:52:51,925 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-7) JBWS024074: WSDL published to: file:/home/remote/klape/work/archives/wildfly-8.1.0.Final/standalone/data/wsdl/ws-java.jar/HelloServiceService.wsdl > {noformat} > Yet when you try to get the WSDL at {{http://localhost:8080/ws-java/HelloService?wsdl}} (pulled from the metadata in the log), you get a 404 error. > JBossWS should not be trying to deploy the POJO endpoint from within an EJB-jar. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 02:36:30 2014 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Fri, 7 Nov 2014 02:36:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3872) Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018125#comment-13018125 ] Alessio Soldano commented on WFLY-3872: --------------------------------------- Thanks [~swd847] Can we perhaps add a link here to the jira or commit in Undertow that fixed this? Thanks > Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn > -------------------------------------------------------------------------------------------- > > Key: WFLY-3872 > URL: https://issues.jboss.org/browse/WFLY-3872 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > Since https://github.com/wildfly/wildfly/pull/6660 was submitted, EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn is failing regularly. Not every time but very often. > Alessio, you mentioned seeing some error logging from XAResourceRecoveryImpl, but that's in the logs on successful runs as well, and occurs prior to the test as well. That's a period background task from the transaction manager trying to perform recovery of some previous transaction. I don't see why it would have any impact on this test. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 02:51:29 2014 From: issues at jboss.org (Takayoshi Kimura (JIRA)) Date: Fri, 7 Nov 2014 02:51:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Takayoshi Kimura updated JGRP-1898: ----------------------------------- Attachment: test-fdhost.zip Tested this change with JGroups 3.6.0 and 3.6.1 and it looks good. Used Byteman to insert delay before each ping. Attached my test and logs. > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 03:03:29 2014 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Fri, 7 Nov 2014 03:03:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client In-Reply-To: References: Message-ID: Alessio Soldano created WFCORE-227: -------------------------------------- Summary: RejectedExecutionException when closing ModelControllerClient client Key: WFCORE-227 URL: https://issues.jboss.org/browse/WFCORE-227 Project: WildFly Core Issue Type: Bug Reporter: Alessio Soldano After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite: {noformat} Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3 at 5651c0c2 rejected from org.xnio.XnioWorker$TaskPool at 11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) at org.xnio.XnioWorker.execute(XnioWorker.java:741) at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363) at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107) at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) {noformat} The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method. The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 03:05:29 2014 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Fri, 7 Nov 2014 03:05:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated WFCORE-227: ----------------------------------- Fix Version/s: 1.0.0.Alpha12 > RejectedExecutionException when closing ModelControllerClient client > -------------------------------------------------------------------- > > Key: WFCORE-227 > URL: https://issues.jboss.org/browse/WFCORE-227 > Project: WildFly Core > Issue Type: Bug > Reporter: Alessio Soldano > Fix For: 1.0.0.Alpha12 > > > After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite: > {noformat} > Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3 at 5651c0c2 rejected from org.xnio.XnioWorker$TaskPool at 11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) > at org.xnio.XnioWorker.execute(XnioWorker.java:741) > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363) > at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method. > The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 03:06:29 2014 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Fri, 7 Nov 2014 03:06:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated WFCORE-227: ----------------------------------- Affects Version/s: 1.0.0.Alpha11 > RejectedExecutionException when closing ModelControllerClient client > -------------------------------------------------------------------- > > Key: WFCORE-227 > URL: https://issues.jboss.org/browse/WFCORE-227 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 1.0.0.Alpha11 > Reporter: Alessio Soldano > Fix For: 1.0.0.Alpha12 > > > After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite: > {noformat} > Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3 at 5651c0c2 rejected from org.xnio.XnioWorker$TaskPool at 11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) > at org.xnio.XnioWorker.execute(XnioWorker.java:741) > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363) > at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method. > The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 03:08:30 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 7 Nov 2014 03:08:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018130#comment-13018130 ] Bela Ban commented on JGRP-1898: -------------------------------- Good. Do you want me to release a version (which one, 3.4.7?), or is a tag good enough ? If you're consuming a Brew-created JAR, then a tag should do the job. > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 03:11:30 2014 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Fri, 7 Nov 2014 03:11:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018132#comment-13018132 ] Alessio Soldano commented on WFCORE-227: ---------------------------------------- http://jbossws-qa.jboss.org:8180/hudson/job/CXF-CORE-AS-9.0.0/191/console > RejectedExecutionException when closing ModelControllerClient client > -------------------------------------------------------------------- > > Key: WFCORE-227 > URL: https://issues.jboss.org/browse/WFCORE-227 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 1.0.0.Alpha11 > Reporter: Alessio Soldano > Fix For: 1.0.0.Alpha12 > > > After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite: > {noformat} > Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3 at 5651c0c2 rejected from org.xnio.XnioWorker$TaskPool at 11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) > at org.xnio.XnioWorker.execute(XnioWorker.java:741) > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363) > at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method. > The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 03:17:30 2014 From: issues at jboss.org (Takayoshi Kimura (JIRA)) Date: Fri, 7 Nov 2014 03:17:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018135#comment-13018135 ] Takayoshi Kimura commented on JGRP-1898: ---------------------------------------- For 3.4 and 3.5 this change was not correctly backported, I'm sending PRs. > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 03:23:29 2014 From: issues at jboss.org (Takayoshi Kimura (JIRA)) Date: Fri, 7 Nov 2014 03:23:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018136#comment-13018136 ] Takayoshi Kimura commented on JGRP-1898: ---------------------------------------- For JDG 6.3 we need 3.4 release. JDG 6.4 uses 3.6 so 3.6.1 is fine. > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 03:26:30 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 7 Nov 2014 03:26:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018137#comment-13018137 ] Bela Ban commented on JGRP-1898: -------------------------------- Sorry for the incorrect backports (fixed now) ! So I'll release 3.4.7. For 3.6.1 I wanted to wait a bit... do you really need it, or is a tag good enough ? > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 03:32:30 2014 From: issues at jboss.org (Takayoshi Kimura (JIRA)) Date: Fri, 7 Nov 2014 03:32:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018140#comment-13018140 ] Takayoshi Kimura commented on JGRP-1898: ---------------------------------------- No problem, I think we can wait. > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 04:54:30 2014 From: issues at jboss.org (=?UTF-8?Q?Marcial_Ati=C3=A9nzar_Navarro_=28JIRA=29?=) Date: Fri, 7 Nov 2014 04:54:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4037) Error 500 accessing png, css, rest In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018178#comment-13018178 ] Marcial Ati?nzar Navarro commented on WFLY-4037: ------------------------------------------------ I can't create a test, is occurs randomly. I can't reproduced it on development environment. I can't upgrade on production to 9.0.0 because it's a alpha version. > Error 500 accessing png,css, rest > --------------------------------- > > Key: WFLY-4037 > URL: https://issues.jboss.org/browse/WFLY-4037 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Marcial Ati?nzar Navarro > Assignee: Paul Ferraro > Priority: Critical > > I've this error: > {code} > 09:37:41,261 ERROR [io.undertow.request] (default task-22) UT005023: Exception handling request to /common/publico/auth/isUsarioAutenticado: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=146}, status=1} is not in a valid state to be invoking cache operations on. > at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:275) > at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:231) > at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:225) > at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:221) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) > at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79) > at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:74) > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40) > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) > at org.infinispan.CacheImpl.get(CacheImpl.java:377) > at org.infinispan.CacheImpl.get(CacheImpl.java:369) > at org.infinispan.AbstractDelegatingCache.get(AbstractDelegatingCache.java:271) > at org.jboss.as.clustering.infinispan.invoker.Locator$FindOperation.invoke(Locator.java:54) > at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34) > at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:77) > at org.wildfly.clustering.web.infinispan.sso.coarse.CoarseSSOFactory.findValue(CoarseSSOFactory.java:38) > at org.wildfly.clustering.web.infinispan.sso.InfinispanSSOManager.findSSO(InfinispanSSOManager.java:50) > at org.wildfly.clustering.web.undertow.sso.DistributableSingleSignOnManager.findSingleSignOn(DistributableSingleSignOnManager.java:77) > at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:53) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25] > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 05:04:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 05:04:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JGRP-1898: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1159162, https://bugzilla.redhat.com/show_bug.cgi?id=1161529 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1159162) > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 05:29:33 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 7 Nov 2014 05:29:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called before all persistence units have performed database updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018195#comment-13018195 ] Michael Musgrove commented on WFLY-3619: ---------------------------------------- Scott, we are already discussing how to proceed re synch ordering on the forums: https://developer.jboss.org/message/909355 The implementation is quite straight forward but we are still discussing the most sensible way forward. > XA END / un-enlist for database connection called before all persistence units have performed database updates > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3619 > URL: https://issues.jboss.org/browse/WFLY-3619 > Project: WildFly > Issue Type: Bug > Components: EJB, JCA, JPA / Hibernate, Transactions > Affects Versions: 8.0.0.Final > Environment: Windows 7 64-bit > JDK 1.8.0_05-b13 64-Bit > MS SQL Server 2012 database > Latest MS JDBC driver > XA datasource > Reporter: Andreas Liebscher > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > Attachments: persistence.xml, server-9.0.0.Alpha1-SNAPHOT-trace.log, server-9.0.0.Alpha1-SNAPHOT.log, server-all-traces-full.log.gz, server-org-jboss-as-jpa.log, server.jca.log, server_MSSQL_Trace.log > > > While trying to port an EE application from JBoss5 to WF8 the following problem occurred: > EJBs (@Required) using JPA to do some data changes. > Some changes get already written to the database, others reside in the session cache. > After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion. > Then more changes are flushed to the database, but I run in a reproduceable database locking problem. > After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call. > There should be exactly one xa transaction active processing all data changes. > But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction. > After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour: > - a connection is enlisted and xa start called > - the same connection is used for several select / insert / update statements > - after return of the top EJB call on the same connection xa end and connection un-enlist is called > - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected. > Shouldn't xa end be called AFTER beforeCompletion / session flush!?! -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 06:04:29 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 7 Nov 2014 06:04:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1899) Discovery returns after 16 responses even if there are no coord responses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-1899: --------------------------- Fix Version/s: 3.5.2 > Discovery returns after 16 responses even if there are no coord responses > ------------------------------------------------------------------------- > > Key: JGRP-1899 > URL: https://issues.jboss.org/browse/JGRP-1899 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.2, 3.6.1 > > > Discovery sets {{Responses.num_expected_rsps}} to 16 if no member list is defined. This makes discovery return after 16 responses even if no response from a coordinator has been received. > This is a problem if we have a cluster of size > 16 and the coordinator doesn't respond imediately, e.g. because it is busy processing other requests. > h5. Solution > * Set {{num_expected_rsps}} to 0 (= wait until at least 1 coord rsp has been received -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 06:04:30 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 7 Nov 2014 06:04:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1899) Discovery returns after 16 responses even if there are no coord responses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban reopened JGRP-1899: ---------------------------- Backport to 3.5.2 > Discovery returns after 16 responses even if there are no coord responses > ------------------------------------------------------------------------- > > Key: JGRP-1899 > URL: https://issues.jboss.org/browse/JGRP-1899 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.2, 3.6.1 > > > Discovery sets {{Responses.num_expected_rsps}} to 16 if no member list is defined. This makes discovery return after 16 responses even if no response from a coordinator has been received. > This is a problem if we have a cluster of size > 16 and the coordinator doesn't respond imediately, e.g. because it is busy processing other requests. > h5. Solution > * Set {{num_expected_rsps}} to 0 (= wait until at least 1 coord rsp has been received -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 06:42:30 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 7 Nov 2014 06:42:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018215#comment-13018215 ] Bela Ban commented on JGRP-1898: -------------------------------- I released 3.4.7 to Nexus and SourceForge. Thanks Takayoshi ! > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 06:55:29 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 7 Nov 2014 06:55:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1899) Discovery returns after 16 responses even if there are no coord responses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban resolved JGRP-1899. ---------------------------- Resolution: Done Backported to 3.5.2 > Discovery returns after 16 responses even if there are no coord responses > ------------------------------------------------------------------------- > > Key: JGRP-1899 > URL: https://issues.jboss.org/browse/JGRP-1899 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.2, 3.6.1 > > > Discovery sets {{Responses.num_expected_rsps}} to 16 if no member list is defined. This makes discovery return after 16 responses even if no response from a coordinator has been received. > This is a problem if we have a cluster of size > 16 and the coordinator doesn't respond imediately, e.g. because it is busy processing other requests. > h5. Solution > * Set {{num_expected_rsps}} to 0 (= wait until at least 1 coord rsp has been received -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 07:40:30 2014 From: issues at jboss.org (David Castro (JIRA)) Date: Fri, 7 Nov 2014 07:40:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-141) Failed to transform class with name com.some.class. Reason: null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018227#comment-13018227 ] David Castro commented on JASSIST-141: -------------------------------------- Hello, I don't know if I should create a new Issue of comment this but I have the same problem described here. I got: Powermock/Mockito 1.5.5 with Javaassist 3.18.2-GA. When I try to mock a class with extends another big class(more tha 6000 lines of code) I get the exception at the end of this post. The curious thing about it is that I wanted to refactor and increase the sonar total quality of this class. Before this, there was no problem with mocking the class. After some refactors and code quality improvements, the unit tests that previously worked fine crashed with this problem java.lang.IllegalStateException: Failed to transform class with name es.company.department.app.commons.applet.sithinlet.thinlet.Thinlet. Reason: null at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:247) at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:177) at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:68) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) at java.lang.ClassLoader.defineClass(ClassLoader.java:615) at java.lang.ClassLoader.defineClass(ClassLoader.java:465) at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:250) at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:177) at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:68) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.privateGetPublicMethods(Class.java:2547) at java.lang.Class.getMethods(Class.java:1410) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getTestMethods(PowerMockJUnit44RunnerDelegateImpl.java:93) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.(PowerMockJUnit44RunnerDelegateImpl.java:69) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl.(PowerMockJUnit47RunnerDelegateImpl.java:42) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit49RunnerDelegateImpl.(PowerMockJUnit49RunnerDelegateImpl.java:25) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:149) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:39) at org.powermock.tests.utils.impl.AbstractTestSuiteChunkerImpl.createTestDelegators(AbstractTestSuiteChunkerImpl.java:218) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.(JUnit4TestSuiteChunkerImpl.java:59) at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.(AbstractCommonPowerMockRunner.java:32) at org.powermock.modules.junit4.PowerMockRunner.(PowerMockRunner.java:33) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26) at org.apache.maven.surefire.junit4.JUnit4TestSet.(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Caused by: java.lang.NullPointerException at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:902) at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:801) at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:597) at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:81) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:187) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:164) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:108) at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423) at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405) at javassist.expr.ExprEditor.doit(ExprEditor.java:113) at javassist.CtClassType.instrument(CtClassType.java:1398) at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:74) at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:243) ... 50 more > Failed to transform class with name com.some.class. Reason: null > ---------------------------------------------------------------- > > Key: JASSIST-141 > URL: https://issues.jboss.org/browse/JASSIST-141 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.14.0.GA > Environment: eclipse, powermock 1.4.8, easymock 3, junit 4.8, javassist 3.14.0.GA > Reporter: Andreas Don'tAskDon'tTell > Assignee: Shigeru Chiba > Labels: mapmaker, powermock > > Hi, > i get this error while using the @PrepareForTest() annotation from the powermock framework. > This framework uses javassist for bytecode manipulation and i think it's more a javassist bug then a powermock bug. > the code i try to parse is 2500 lines long (i know bad bad bad code but it's not mine, i only need to test it). i do not want to post all. If you could help me to debug the hole file with javassist to find the methodes or statments that produces this error, i am happy to do so. Is there some debuging level or something to check where javassist crashes? > Thankyou for now :D > Yours, > Andreas > and here the stacktrace: > java.lang.IllegalStateException: Failed to transform class with name com.some.class. Reason: null > at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:207) > at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:145) > at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:65) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:247) > at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:95) > at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:107) > at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31) > at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:370) > at sun.reflect.annotation.AnnotationParser.parseClassValue(AnnotationParser.java:351) > at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653) > at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460) > at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286) > at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222) > at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69) > at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52) > at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070) > at java.lang.Class.getAnnotations(Class.java:3050) > at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.classAnnotations(PowerMockJUnit44RunnerDelegateImpl.java:163) > at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getDescription(PowerMockJUnit44RunnerDelegateImpl.java:155) > at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.getDescription(JUnit4TestSuiteChunkerImpl.java:172) > at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.getDescription(AbstractCommonPowerMockRunner.java:47) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.sendTree(JUnit4TestClassReference.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.sendTrees(RemoteTestRunner.java:476) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:464) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) > Caused by: java.lang.NullPointerException > at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:888) > at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:822) > at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:620) > at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:102) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:182) > at javassist.bytecode.stackmap.MapMaker.traceException(MapMaker.java:213) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:175) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > ===================================================================================================================== > 243 times this line : at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > ===================================================================================================================== > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:141) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:96) > at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:416) > at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:398) > at javassist.expr.ExprEditor.doit(ExprEditor.java:112) > at javassist.CtClassType.instrument(CtClassType.java:1384) > at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:77) > at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203) > ... 28 more -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 07:40:31 2014 From: issues at jboss.org (David Castro (JIRA)) Date: Fri, 7 Nov 2014 07:40:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-141) Failed to transform class with name com.some.class. Reason: null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018227#comment-13018227 ] David Castro edited comment on JASSIST-141 at 11/7/14 7:40 AM: --------------------------------------------------------------- Hello, I don't know if I should create a new Issue or comment this but I have the same problem described here. I got: Powermock/Mockito 1.5.5 with Javaassist 3.18.2-GA. When I try to mock a class with extends another big class(more tha 6000 lines of code) I get the exception at the end of this post. The curious thing about it is that I wanted to refactor and increase the sonar total quality of this class. Before this, there was no problem with mocking the class. After some refactors and code quality improvements, the unit tests that previously worked fine crashed with this problem java.lang.IllegalStateException: Failed to transform class with name es.company.department.app.commons.applet.sithinlet.thinlet.Thinlet. Reason: null at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:247) at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:177) at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:68) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) at java.lang.ClassLoader.defineClass(ClassLoader.java:615) at java.lang.ClassLoader.defineClass(ClassLoader.java:465) at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:250) at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:177) at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:68) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.privateGetPublicMethods(Class.java:2547) at java.lang.Class.getMethods(Class.java:1410) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getTestMethods(PowerMockJUnit44RunnerDelegateImpl.java:93) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.(PowerMockJUnit44RunnerDelegateImpl.java:69) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl.(PowerMockJUnit47RunnerDelegateImpl.java:42) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit49RunnerDelegateImpl.(PowerMockJUnit49RunnerDelegateImpl.java:25) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:149) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:39) at org.powermock.tests.utils.impl.AbstractTestSuiteChunkerImpl.createTestDelegators(AbstractTestSuiteChunkerImpl.java:218) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.(JUnit4TestSuiteChunkerImpl.java:59) at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.(AbstractCommonPowerMockRunner.java:32) at org.powermock.modules.junit4.PowerMockRunner.(PowerMockRunner.java:33) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26) at org.apache.maven.surefire.junit4.JUnit4TestSet.(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Caused by: java.lang.NullPointerException at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:902) at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:801) at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:597) at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:81) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:187) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:164) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:108) at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423) at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405) at javassist.expr.ExprEditor.doit(ExprEditor.java:113) at javassist.CtClassType.instrument(CtClassType.java:1398) at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:74) at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:243) ... 50 more was (Author: eorahil): Hello, I don't know if I should create a new Issue of comment this but I have the same problem described here. I got: Powermock/Mockito 1.5.5 with Javaassist 3.18.2-GA. When I try to mock a class with extends another big class(more tha 6000 lines of code) I get the exception at the end of this post. The curious thing about it is that I wanted to refactor and increase the sonar total quality of this class. Before this, there was no problem with mocking the class. After some refactors and code quality improvements, the unit tests that previously worked fine crashed with this problem java.lang.IllegalStateException: Failed to transform class with name es.company.department.app.commons.applet.sithinlet.thinlet.Thinlet. Reason: null at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:247) at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:177) at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:68) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) at java.lang.ClassLoader.defineClass(ClassLoader.java:615) at java.lang.ClassLoader.defineClass(ClassLoader.java:465) at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:250) at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:177) at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:68) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.privateGetPublicMethods(Class.java:2547) at java.lang.Class.getMethods(Class.java:1410) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getTestMethods(PowerMockJUnit44RunnerDelegateImpl.java:93) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.(PowerMockJUnit44RunnerDelegateImpl.java:69) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl.(PowerMockJUnit47RunnerDelegateImpl.java:42) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit49RunnerDelegateImpl.(PowerMockJUnit49RunnerDelegateImpl.java:25) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:149) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:39) at org.powermock.tests.utils.impl.AbstractTestSuiteChunkerImpl.createTestDelegators(AbstractTestSuiteChunkerImpl.java:218) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.(JUnit4TestSuiteChunkerImpl.java:59) at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.(AbstractCommonPowerMockRunner.java:32) at org.powermock.modules.junit4.PowerMockRunner.(PowerMockRunner.java:33) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:29) at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:21) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26) at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26) at org.apache.maven.surefire.junit4.JUnit4TestSet.(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Caused by: java.lang.NullPointerException at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:902) at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:801) at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:597) at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:81) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:187) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:199) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:164) at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:108) at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423) at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405) at javassist.expr.ExprEditor.doit(ExprEditor.java:113) at javassist.CtClassType.instrument(CtClassType.java:1398) at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:74) at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:243) ... 50 more > Failed to transform class with name com.some.class. Reason: null > ---------------------------------------------------------------- > > Key: JASSIST-141 > URL: https://issues.jboss.org/browse/JASSIST-141 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.14.0.GA > Environment: eclipse, powermock 1.4.8, easymock 3, junit 4.8, javassist 3.14.0.GA > Reporter: Andreas Don'tAskDon'tTell > Assignee: Shigeru Chiba > Labels: mapmaker, powermock > > Hi, > i get this error while using the @PrepareForTest() annotation from the powermock framework. > This framework uses javassist for bytecode manipulation and i think it's more a javassist bug then a powermock bug. > the code i try to parse is 2500 lines long (i know bad bad bad code but it's not mine, i only need to test it). i do not want to post all. If you could help me to debug the hole file with javassist to find the methodes or statments that produces this error, i am happy to do so. Is there some debuging level or something to check where javassist crashes? > Thankyou for now :D > Yours, > Andreas > and here the stacktrace: > java.lang.IllegalStateException: Failed to transform class with name com.some.class. Reason: null > at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:207) > at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:145) > at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:65) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:247) > at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:95) > at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:107) > at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31) > at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:370) > at sun.reflect.annotation.AnnotationParser.parseClassValue(AnnotationParser.java:351) > at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653) > at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460) > at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286) > at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222) > at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69) > at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52) > at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070) > at java.lang.Class.getAnnotations(Class.java:3050) > at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.classAnnotations(PowerMockJUnit44RunnerDelegateImpl.java:163) > at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getDescription(PowerMockJUnit44RunnerDelegateImpl.java:155) > at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.getDescription(JUnit4TestSuiteChunkerImpl.java:172) > at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.getDescription(AbstractCommonPowerMockRunner.java:47) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.sendTree(JUnit4TestClassReference.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.sendTrees(RemoteTestRunner.java:476) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:464) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) > Caused by: java.lang.NullPointerException > at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:888) > at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:822) > at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:620) > at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:102) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:182) > at javassist.bytecode.stackmap.MapMaker.traceException(MapMaker.java:213) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:175) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > ===================================================================================================================== > 243 times this line : at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > ===================================================================================================================== > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:141) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:96) > at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:416) > at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:398) > at javassist.expr.ExprEditor.doit(ExprEditor.java:112) > at javassist.CtClassType.instrument(CtClassType.java:1384) > at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:77) > at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203) > ... 28 more -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 07:46:32 2014 From: issues at jboss.org (Sanne Grinovero (JIRA)) Date: Fri, 7 Nov 2014 07:46:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-106) Log4jLoggerProvider clearNdc doesn't clear Ndc reference to threads In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanne Grinovero updated JBLOGGING-106: -------------------------------------- Fix Version/s: 3.2.0.Beta2 > Log4jLoggerProvider clearNdc doesn't clear Ndc reference to threads > ------------------------------------------------------------------- > > Key: JBLOGGING-106 > URL: https://issues.jboss.org/browse/JBLOGGING-106 > Project: JBoss Logging > Issue Type: Bug > Components: jboss-logging-log4j > Affects Versions: 3.1.2.GA > Reporter: William Burns > Assignee: James Perkins > Fix For: 3.2.0.Beta2 > > > The Log4jLoggerProvider have a method clearNdc on it that calls to the NDC.clear method. Unfortunately this method only clears the Stack that log4j1.2 holds internally in it's NDC class. Unfortunately this leaves the entry still in the NDC class for the current thread pointing to that stack. If we use the remove method instead it will remove the entry from the NDC Hashtable and allow the thread to be GC'd if it is no longer running and referenced. > Without this change there is no way to clear the NDC table which will eventually cause an OOM unless we call directly into the log4j NDC class to clear it. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:09:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 08:09:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-795) jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018242#comment-13018242 ] RH Bugzilla Integration commented on WFLY-795: ---------------------------------------------- Stefan Guilhen changed the Status of [bug 1028412|https://bugzilla.redhat.com/show_bug.cgi?id=1028412] from NEW to ASSIGNED > jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements > -------------------------------------------------------------------------------------- > > Key: WFLY-795 > URL: https://issues.jboss.org/browse/WFLY-795 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: James Livingston > Assignee: David Lloyd > Fix For: 8.0.0.CR1 > > > In jboss-ejb-iiop_1_0.xsd, the "integrity", "confidentiality", "establish-trust-in-client", and "establish-trust-in-target" attributes on the "iorTransportConfigType" complexType, and the "auth-method", "realm" and "required" attributes on the "iorASContextType" complexType have both use="required" and a default attribute. > This does not make sense because default values are only applicable to optional attributes. I'm not sure which is correct, but either the attributes should be optional or the default values removed. This problem causes the XSD to not validate. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:29:31 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 7 Nov 2014 08:29:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SASL-71) Add a GSSAPI SaslServer mechanism to wrap the JDK supplied impl In-Reply-To: References: Message-ID: Darran Lofthouse created SASL-71: ------------------------------------ Summary: Add a GSSAPI SaslServer mechanism to wrap the JDK supplied impl Key: SASL-71 URL: https://issues.jboss.org/browse/SASL-71 Project: SASL Provider Issue Type: Feature Request Components: GSSAPI Mechanism Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.5.CR1 The main purpose of this wrapper is so that it can be passed a factory for obtaining Subjects otherwise the code creating the SaslServer instance is always going to need to be checking what type of SaslServer it is creating and manage the Subjects itself. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:31:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 7 Nov 2014 08:31:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-122) Make use of factory from SASL-71 to obtain Subject for GSSAPI In-Reply-To: References: Message-ID: Darran Lofthouse created ELY-122: ------------------------------------ Summary: Make use of factory from SASL-71 to obtain Subject for GSSAPI Key: ELY-122 URL: https://issues.jboss.org/browse/ELY-122 Project: WildFly Elytron Issue Type: Feature Request Components: SASL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Beta1 By default we rely on the AccessControlContext in place at the time the SaslServer is created, the use of a factory allows greater control of the Subject in use especially in a managed environment. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:48:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 08:48:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3905) POJO JAX-WS endpoints should not be processed if packaged in EJB-jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018275#comment-13018275 ] RH Bugzilla Integration commented on WFLY-3905: ----------------------------------------------- Kabir Khan changed the Status of [bug 1147657|https://bugzilla.redhat.com/show_bug.cgi?id=1147657] from POST to MODIFIED > POJO JAX-WS endpoints should not be processed if packaged in EJB-jar > -------------------------------------------------------------------- > > Key: WFLY-3905 > URL: https://issues.jboss.org/browse/WFLY-3905 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Kyle Lape > Assignee: Kyle Lape > Fix For: 9.0.0.Beta1 > > > If a POJO is defined like this in an EJB-jar: > {code:java} > package com.redhat.gss.ws; > @javax.jws.WebService > public class HelloService { > public String sayHello() { > return "Hello World!"; > } > } > {code} > Deployment structure: > {noformat} > klape at localhost ws-java.jar$ tree > . > ??? com > ??? ??? redhat > ??? ??? gss > ??? ??? ws > ??? ??? HelloService.java > ??? META-INF > ??? MANIFEST.MF > 5 directories, 2 files > klape at localhost ws-java.jar$ > {noformat} > Upon deployment, you get this in the log: > {noformat} > 16:52:51,372 INFO [org.jboss.ws.cxf.metadata] (MSC service thread 1-7) JBWS024061: Adding service endpoint metadata: id=com.redhat.gss.ws.HelloService > address=http://localhost:8080/ws-java/HelloService > implementor=com.redhat.gss.ws.HelloService > serviceName={http://ws.gss.redhat.com/}HelloServiceService > portName={http://ws.gss.redhat.com/}HelloServicePort > annotationWsdlLocation=null > wsdlLocationOverride=null > mtomEnabled=false > 16:52:51,571 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-7) Creating Service {http://ws.gss.redhat.com/}HelloServiceService from class com.redhat.gss.ws.HelloService > 16:52:51,879 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-7) Setting the server's publish address to be http://localhost:8080/ws-java/HelloService > 16:52:51,925 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-7) JBWS024074: WSDL published to: file:/home/remote/klape/work/archives/wildfly-8.1.0.Final/standalone/data/wsdl/ws-java.jar/HelloServiceService.wsdl > {noformat} > Yet when you try to get the WSDL at {{http://localhost:8080/ws-java/HelloService?wsdl}} (pulled from the metadata in the log), you get a 404 error. > JBossWS should not be trying to deploy the POJO endpoint from within an EJB-jar. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:51:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 08:51:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-851) Base64Utils class cuts leading zeroes from encoded bytes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018276#comment-13018276 ] RH Bugzilla Integration commented on SECURITY-851: -------------------------------------------------- Peter Skopek changed the Status of [bug 1125004|https://bugzilla.redhat.com/show_bug.cgi?id=1125004] from ASSIGNED to POST > Base64Utils class cuts leading zeroes from encoded bytes > -------------------------------------------------------- > > Key: SECURITY-851 > URL: https://issues.jboss.org/browse/SECURITY-851 > Project: PicketBox > Issue Type: Bug > Affects Versions: PicketBox_4_0_21.Beta2 > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Blocker > Fix For: PicketBox_4_0_21.Beta4 > > > Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array. > So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes. > For instance: > {code} > encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho" > decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 } > {code} > As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException. > IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:52:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 08:52:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-764) Enhance the security realm plug-in mechanism for client-cert / external verification. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018279#comment-13018279 ] RH Bugzilla Integration commented on WFLY-764: ---------------------------------------------- Kabir Khan changed the Status of [bug 953200|https://bugzilla.redhat.com/show_bug.cgi?id=953200] from POST to MODIFIED > Enhance the security realm plug-in mechanism for client-cert / external verification. > ------------------------------------------------------------------------------------- > > Key: WFLY-764 > URL: https://issues.jboss.org/browse/WFLY-764 > Project: WildFly > Issue Type: Task > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Labels: Realm_Management > Fix For: Awaiting Volunteers > > > Currently verification is just based on the defined trust store - this is to take it one step further and allow an optional additional verification. > As a first step will need to ensure we have a suitable Callback from the authenticator to the realm to verify the identity and then this can be passed on to the plug-in. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:52:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 08:52:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3580) Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018278#comment-13018278 ] RH Bugzilla Integration commented on WFLY-3580: ----------------------------------------------- Kabir Khan changed the Status of [bug 953200|https://bugzilla.redhat.com/show_bug.cgi?id=953200] from POST to MODIFIED > Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3580 > URL: https://issues.jboss.org/browse/WFLY-3580 > Project: WildFly > Issue Type: Bug > Components: Domain Management, EJB > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection. This makes it impossible to get the certificate for use in a custom login module. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:52:32 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 08:52:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018280#comment-13018280 ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Kabir Khan changed the Status of [bug 1149618|https://bugzilla.redhat.com/show_bug.cgi?id=1149618] from POST to MODIFIED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:54:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 08:54:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4060) Intermittent failures on SendMessage testcase when running with JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018284#comment-13018284 ] RH Bugzilla Integration commented on WFLY-4060: ----------------------------------------------- Kabir Khan changed the Status of [bug 1160761|https://bugzilla.redhat.com/show_bug.cgi?id=1160761] from NEW to MODIFIED > Intermittent failures on SendMessage testcase when running with JTS > ------------------------------------------------------------------- > > Key: WFLY-4060 > URL: https://issues.jboss.org/browse/WFLY-4060 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ond?ej Chaloupka > Assignee: Ond?ej Chaloupka > > During testing EAP I was hitting intermittent failures on SendMessageTestscase which was caused by timing issues. > There is a bit more explanation of reasons at bz: https://bugzilla.redhat.com/show_bug.cgi?id=1160761 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:55:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 08:55:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-220) cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018285#comment-13018285 ] RH Bugzilla Integration commented on WFCORE-220: ------------------------------------------------ Kabir Khan changed the Status of [bug 1103620|https://bugzilla.redhat.com/show_bug.cgi?id=1103620] from POST to MODIFIED > cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored > ---------------------------------------------------------------------- > > Key: WFCORE-220 > URL: https://issues.jboss.org/browse/WFCORE-220 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Scripts > Reporter: Alexey Loubyansky > Assignee: James Perkins > > E.g. ./jboss-cli.sh -Djboss.cli.config=/jboss-cli.xml > The system property won't be set, instead the argument will treated as simply a command line argument. > This has to be fixed in the scripts themselves launching the CLI. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:55:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 08:55:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018286#comment-13018286 ] RH Bugzilla Integration commented on WFCORE-160: ------------------------------------------------ Kabir Khan changed the Status of [bug 1145960|https://bugzilla.redhat.com/show_bug.cgi?id=1145960] from POST to MODIFIED > Bash scripts should not attempt to expand argument properties > ------------------------------------------------------------- > > Key: WFCORE-160 > URL: https://issues.jboss.org/browse/WFCORE-160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha10 > > > Scripts that parse the command line arguments use a pattern like > {code} > while [ "$#" -gt 0 ] > do > case "$1" in > *) > CLI_OPTS="$CLI_OPTS \"$1\"" > ;; > esac > shift > done > {code} > The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:56:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 08:56:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-158) Handlers should not be allowed to be removed if they're assigned to another handler or logger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018288#comment-13018288 ] RH Bugzilla Integration commented on WFCORE-158: ------------------------------------------------ Kabir Khan changed the Status of [bug 1007333|https://bugzilla.redhat.com/show_bug.cgi?id=1007333] from POST to MODIFIED > Handlers should not be allowed to be removed if they're assigned to another handler or logger > --------------------------------------------------------------------------------------------- > > Key: WFCORE-158 > URL: https://issues.jboss.org/browse/WFCORE-158 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha12 > > > Handlers can currently be removed even if the handler is assigned to a logger or another handler. This allows an invalid {{logging.properties}} file to be written and will fail to start the server on the next boot. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 08:57:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 08:57:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-159) Handlers can be created with the same name as an existing handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018289#comment-13018289 ] RH Bugzilla Integration commented on WFCORE-159: ------------------------------------------------ Kabir Khan changed the Status of [bug 1151256|https://bugzilla.redhat.com/show_bug.cgi?id=1151256] from POST to MODIFIED > Handlers can be created with the same name as an existing handler > ----------------------------------------------------------------- > > Key: WFCORE-159 > URL: https://issues.jboss.org/browse/WFCORE-159 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha12 > > > Handlers can be created with the same name as an existing handler. This was done to reconfigure differences in the logging subsystem XML and the logging.properties file. The problem is it will replace a handler during an {{ADD}} operation if the same name is used on another parent resource. > {code} > /subsystem=logging/async-handler=CONSOLE:add(queue-length=10,overflow-action=BLOCK) > {code} > This will replace the default console handler with the new one keeping the existing console-handler resource. The next boot also fails with no indication on the console. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 09:04:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 7 Nov 2014 09:04:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-99) standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar resolved WFCORE-99. ------------------------------- Fix Version/s: 1.0.0.Alpha9 Resolution: Done > standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly > ----------------------------------------------------------------------------- > > Key: WFCORE-99 > URL: https://issues.jboss.org/browse/WFCORE-99 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 1.0.0.Alpha6 > Environment: Windows OS > Reporter: Jay Kumar SenSharma > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha9 > > > *Scenario -1* > - With the following line of JAVA_OPTS in "standalone.bat.conf" file > {code} > set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost|127.0.0.1|10.10.10.*" > {code} > Error while starting WildFly > {code} > C:\wildfly-9.0.0.Alpha1-SNAPSHOT\bin>standalone.bat > Calling "C:\wildfly-9.0.0.Alpha1-SNAPSHOT\bin\standalone.conf.bat" > Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java" > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > {code} > *Scenario -2* > - In Windows "^" sign is the escape character so we tried altering the JAVA_OPTS as following in the "standalone.bat.conf" file: > {code} > set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost^|127.0.0.1^|10.10.10.*" > {code} > Now WildFly server starts but still we see the following messages in windows console: > {code} > C:\wildfly-9.0.0.Alpha1-SNAPSHOT\bin>standalone.bat > Calling "C:\wildfly-9.0.0.Alpha1-SNAPSHOT\bin\standalone.conf.bat" > Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java" > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > =============================================================================== > JBoss Bootstrap Environment > JBOSS_HOME: "C:\wildfly-9.0.0.Alpha1-SNAPSHOT" > JAVA: "C:\JDKs\jdk1.7.0_67\bin\java" > JAVA_OPTS: "-client -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs= > org.jboss.byteman -Dhttp.nonProxyHosts=localhost^|127.0.0.1^|10.10.10.*" > =============================================================================== > 15:50:35,453 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.4.Final > 15:50:35,781 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final > 15:50:35,953 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly 1.0.0.Alpha5 "Kenny" starting > {code} > *NOTE*: It is also not possible to pass such JAVA_OPTS via command line, because it causes the same error: > {code} > C:\wildfly-9.0.0.Alpha1-SNAPSHOT\bin>standalone.bat -Dhttp.nonProxyHosts=localhost|127.0.0.1|10.10.10.* > '127.0.0.1' is not recognized as an internal or external command, > operable program or batch file. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 09:07:29 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 7 Nov 2014 09:07:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2348) standalone.bat very slow In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-2348: --------------------------------- Assignee: Tomaz Cerar > standalone.bat very slow > ------------------------ > > Key: WFLY-2348 > URL: https://issues.jboss.org/browse/WFLY-2348 > Project: WildFly > Issue Type: Enhancement > Components: Scripts > Affects Versions: 8.0.0.Beta1 > Reporter: Philippe Marschall > Assignee: Tomaz Cerar > > With a plain WildFly AS downloaded and executing {code}standalone.bat{code} we see about two to three seconds spent in this loop: > {code} > rem Setup directories, note directories with spaces do not work > set "CONSOLIDATED_OPTS=%JAVA_OPTS% %SERVER_OPTS%" > :DIRLOOP > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.base.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_BASE_DIR=%%~fi" > ) > ) > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.config.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_CONFIG_DIR=%%~fi" > ) > ) > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.log.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_LOG_DIR=%%~fi" > ) > ) > for /f "tokens=1* delims= " %%i IN ("%CONSOLIDATED_OPTS%") DO ( > if %%i == "" ( > goto ENDDIRLOOP > ) else ( > set CONSOLIDATED_OPTS=%%j > GOTO DIRLOOP > ) > ) > :ENDDIRLOOP > {code} > It does not seem to define any variables by default, simply removing the code noticeably reduces start up time. > Windows 7, 64 bit, SSD -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 09:08:29 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 7 Nov 2014 09:08:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-228) standalone.bat very slow In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar moved WFLY-2348 to WFCORE-228: ------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-228 (was: WFLY-2348) Affects Version/s: (was: 8.0.0.Beta1) Component/s: Scripts (was: Scripts) > standalone.bat very slow > ------------------------ > > Key: WFCORE-228 > URL: https://issues.jboss.org/browse/WFCORE-228 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Reporter: Philippe Marschall > Assignee: Tomaz Cerar > > With a plain WildFly AS downloaded and executing {code}standalone.bat{code} we see about two to three seconds spent in this loop: > {code} > rem Setup directories, note directories with spaces do not work > set "CONSOLIDATED_OPTS=%JAVA_OPTS% %SERVER_OPTS%" > :DIRLOOP > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.base.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_BASE_DIR=%%~fi" > ) > ) > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.config.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_CONFIG_DIR=%%~fi" > ) > ) > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.log.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_LOG_DIR=%%~fi" > ) > ) > for /f "tokens=1* delims= " %%i IN ("%CONSOLIDATED_OPTS%") DO ( > if %%i == "" ( > goto ENDDIRLOOP > ) else ( > set CONSOLIDATED_OPTS=%%j > GOTO DIRLOOP > ) > ) > :ENDDIRLOOP > {code} > It does not seem to define any variables by default, simply removing the code noticeably reduces start up time. > Windows 7, 64 bit, SSD -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 09:25:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 7 Nov 2014 09:25:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-228) standalone.bat very slow In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFCORE-228: ------------------------------- Fix Version/s: 1.0.0.Alpha12 > standalone.bat very slow > ------------------------ > > Key: WFCORE-228 > URL: https://issues.jboss.org/browse/WFCORE-228 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Reporter: Philippe Marschall > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha12 > > > With a plain WildFly AS downloaded and executing {code}standalone.bat{code} we see about two to three seconds spent in this loop: > {code} > rem Setup directories, note directories with spaces do not work > set "CONSOLIDATED_OPTS=%JAVA_OPTS% %SERVER_OPTS%" > :DIRLOOP > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.base.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_BASE_DIR=%%~fi" > ) > ) > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.config.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_CONFIG_DIR=%%~fi" > ) > ) > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.log.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_LOG_DIR=%%~fi" > ) > ) > for /f "tokens=1* delims= " %%i IN ("%CONSOLIDATED_OPTS%") DO ( > if %%i == "" ( > goto ENDDIRLOOP > ) else ( > set CONSOLIDATED_OPTS=%%j > GOTO DIRLOOP > ) > ) > :ENDDIRLOOP > {code} > It does not seem to define any variables by default, simply removing the code noticeably reduces start up time. > Windows 7, 64 bit, SSD -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 10:01:31 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Fri, 7 Nov 2014 10:01:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-141) Failed to transform class with name com.some.class. Reason: null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018324#comment-13018324 ] Shigeru Chiba commented on JASSIST-141: --------------------------------------- Did you try the latest snapshot of javassist.jar? It is available from: https://github.com/jboss-javassist/javassist The stack trace seems to indicate that the class file after the modification by powermock/javassist is broken. The NullPointerException says that the constant pool (the symbol table) is broken. Could you get that class file? > Failed to transform class with name com.some.class. Reason: null > ---------------------------------------------------------------- > > Key: JASSIST-141 > URL: https://issues.jboss.org/browse/JASSIST-141 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.14.0.GA > Environment: eclipse, powermock 1.4.8, easymock 3, junit 4.8, javassist 3.14.0.GA > Reporter: Andreas Don'tAskDon'tTell > Assignee: Shigeru Chiba > Labels: mapmaker, powermock > > Hi, > i get this error while using the @PrepareForTest() annotation from the powermock framework. > This framework uses javassist for bytecode manipulation and i think it's more a javassist bug then a powermock bug. > the code i try to parse is 2500 lines long (i know bad bad bad code but it's not mine, i only need to test it). i do not want to post all. If you could help me to debug the hole file with javassist to find the methodes or statments that produces this error, i am happy to do so. Is there some debuging level or something to check where javassist crashes? > Thankyou for now :D > Yours, > Andreas > and here the stacktrace: > java.lang.IllegalStateException: Failed to transform class with name com.some.class. Reason: null > at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:207) > at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:145) > at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:65) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:247) > at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:95) > at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:107) > at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31) > at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:370) > at sun.reflect.annotation.AnnotationParser.parseClassValue(AnnotationParser.java:351) > at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653) > at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460) > at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286) > at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222) > at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69) > at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52) > at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070) > at java.lang.Class.getAnnotations(Class.java:3050) > at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.classAnnotations(PowerMockJUnit44RunnerDelegateImpl.java:163) > at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getDescription(PowerMockJUnit44RunnerDelegateImpl.java:155) > at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.getDescription(JUnit4TestSuiteChunkerImpl.java:172) > at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.getDescription(AbstractCommonPowerMockRunner.java:47) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.sendTree(JUnit4TestClassReference.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.sendTrees(RemoteTestRunner.java:476) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:464) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) > Caused by: java.lang.NullPointerException > at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:888) > at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:822) > at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:620) > at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:102) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:182) > at javassist.bytecode.stackmap.MapMaker.traceException(MapMaker.java:213) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:175) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > ===================================================================================================================== > 243 times this line : at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > ===================================================================================================================== > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:141) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:96) > at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:416) > at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:398) > at javassist.expr.ExprEditor.doit(ExprEditor.java:112) > at javassist.CtClassType.instrument(CtClassType.java:1384) > at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:77) > at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203) > ... 28 more -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 10:20:29 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Fri, 7 Nov 2014 10:20:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-229) server-config operation "leaks" to children resources In-Reply-To: References: Message-ID: Jeff Mesnil created WFCORE-229: ---------------------------------- Summary: server-config operation "leaks" to children resources Key: WFCORE-229 URL: https://issues.jboss.org/browse/WFCORE-229 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha11 Reporter: Jeff Mesnil Assignee: Brian Stansberry Start a regular domain Any operations on server children with the same names that server-config operations (:start, :stop, :restart, :kill) are executed instead of being rejected because the actual resources at the operation address does not define them. Examples: {noformat} [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:start { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.util.NoSuchElementException: No child 'undertow' exists", "rolled-back" => true } [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:stop { "outcome" => "success", "result" => "STOPPED" } [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:kill {"outcome" => "success"} {noformat} If the corresponding server-config resource is actually stopped, the operations fail because there is no resource at the operation's address. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 10:20:30 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Fri, 7 Nov 2014 10:20:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-229) server-config operations "leaks" to children resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil updated WFCORE-229: ------------------------------- Summary: server-config operations "leaks" to children resources (was: server-config operation "leaks" to children resources) > server-config operations "leaks" to children resources > ------------------------------------------------------ > > Key: WFCORE-229 > URL: https://issues.jboss.org/browse/WFCORE-229 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Jeff Mesnil > Assignee: Brian Stansberry > > Start a regular domain > Any operations on server children with the same names that server-config operations (:start, :stop, :restart, :kill) are executed instead of being rejected because the actual resources at the operation address does not define them. > Examples: > {noformat} > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:start > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.util.NoSuchElementException: No child 'undertow' exists", > "rolled-back" => true > } > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:stop > { > "outcome" => "success", > "result" => "STOPPED" > } > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:kill > {"outcome" => "success"} > {noformat} > If the corresponding server-config resource is actually stopped, the operations fail because there is no resource at the operation's address. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 10:21:30 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Fri, 7 Nov 2014 10:21:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-229) server-config operations "leaks" to server's resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil updated WFCORE-229: ------------------------------- Summary: server-config operations "leaks" to server's resources (was: server-config operations "leaks" to children resources) > server-config operations "leaks" to server's resources > ------------------------------------------------------ > > Key: WFCORE-229 > URL: https://issues.jboss.org/browse/WFCORE-229 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Jeff Mesnil > Assignee: Brian Stansberry > > Start a regular domain > Any operations on server children with the same names that server-config operations (:start, :stop, :restart, :kill) are executed instead of being rejected because the actual resources at the operation address does not define them. > Examples: > {noformat} > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:start > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.util.NoSuchElementException: No child 'undertow' exists", > "rolled-back" => true > } > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:stop > { > "outcome" => "success", > "result" => "STOPPED" > } > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:kill > {"outcome" => "success"} > {noformat} > If the corresponding server-config resource is actually stopped, the operations fail because there is no resource at the operation's address. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 10:21:30 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Fri, 7 Nov 2014 10:21:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-229) server-config operations "leaks" to server's resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil updated WFCORE-229: ------------------------------- Description: Start a regular domain Any operations on server children with the same names that server-config operations (:start, :stop, :restart, :kill) are executed instead of being rejected because the actual resources at the operation address does not define them. Examples: {noformat} [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:start { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.util.NoSuchElementException: No child 'undertow' exists", "rolled-back" => true } => [Host Controller] 16:15:30,231 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 15) WFLYCTL0013: Operation ("restart") failed - address: ([ [Host Controller] ("host" => "master"), [Host Controller] ("server" => "server-one"), [Host Controller] ("subsystem" => "undertow") [Host Controller] ]) - failure description: "WFLYHC0047: Cannot restart server undertow as it is not currently started; it is STOPPED" [Host Controller] 16:18:43,764 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("start") failed - address: ([ [Host Controller] ("host" => "master"), [Host Controller] ("server" => "server-one"), [Host Controller] ("subsystem" => "undertow") [Host Controller] ]): java.util.NoSuchElementException: No child 'undertow' exists [Host Controller] at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:369) [Host Controller] at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:299) [Host Controller] at org.jboss.dmr.ModelNode.require(ModelNode.java:870) [Host Controller] at org.jboss.as.host.controller.ManagedServerBootCmdFactory.(ManagedServerBootCmdFactory.java:93) [Host Controller] at org.jboss.as.host.controller.ServerInventoryImpl.createBootFactory(ServerInventoryImpl.java:629) [Host Controller] at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:200) [Host Controller] at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:110) [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:728) [Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:563) [Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:336) [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:312) [Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1160) [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:356) [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:215) [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:220) [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:147) [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:169) [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:165) [Host Controller] at java.security.AccessController.doPrivileged(Native Method) [Host Controller] at javax.security.auth.Subject.doAs(Subject.java:422) [Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:165) [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298) [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [Host Controller] at java.lang.Thread.run(Thread.java:745) [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:320) [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:stop { "outcome" => "success", "result" => "STOPPED" } [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:kill {"outcome" => "success"} {noformat} If the corresponding server-config resource is actually stopped, the operations fail because there is no resource at the operation's address. was: Start a regular domain Any operations on server children with the same names that server-config operations (:start, :stop, :restart, :kill) are executed instead of being rejected because the actual resources at the operation address does not define them. Examples: {noformat} [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:start { "outcome" => "failed", "failure-description" => "WFLYCTL0158: Operation handler failed: java.util.NoSuchElementException: No child 'undertow' exists", "rolled-back" => true } [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:stop { "outcome" => "success", "result" => "STOPPED" } [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:kill {"outcome" => "success"} {noformat} If the corresponding server-config resource is actually stopped, the operations fail because there is no resource at the operation's address. > server-config operations "leaks" to server's resources > ------------------------------------------------------ > > Key: WFCORE-229 > URL: https://issues.jboss.org/browse/WFCORE-229 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Jeff Mesnil > Assignee: Brian Stansberry > > Start a regular domain > Any operations on server children with the same names that server-config operations (:start, :stop, :restart, :kill) are executed instead of being rejected because the actual resources at the operation address does not define them. > Examples: > {noformat} > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:start > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.util.NoSuchElementException: No child 'undertow' exists", > "rolled-back" => true > } > => > [Host Controller] 16:15:30,231 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 15) WFLYCTL0013: Operation ("restart") failed - address: ([ > [Host Controller] ("host" => "master"), > [Host Controller] ("server" => "server-one"), > [Host Controller] ("subsystem" => "undertow") > [Host Controller] ]) - failure description: "WFLYHC0047: Cannot restart server undertow as it is not currently started; it is STOPPED" > [Host Controller] 16:18:43,764 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("start") failed - address: ([ > [Host Controller] ("host" => "master"), > [Host Controller] ("server" => "server-one"), > [Host Controller] ("subsystem" => "undertow") > [Host Controller] ]): java.util.NoSuchElementException: No child 'undertow' exists > [Host Controller] at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:369) > [Host Controller] at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:299) > [Host Controller] at org.jboss.dmr.ModelNode.require(ModelNode.java:870) > [Host Controller] at org.jboss.as.host.controller.ManagedServerBootCmdFactory.(ManagedServerBootCmdFactory.java:93) > [Host Controller] at org.jboss.as.host.controller.ServerInventoryImpl.createBootFactory(ServerInventoryImpl.java:629) > [Host Controller] at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:200) > [Host Controller] at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:110) > [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:728) > [Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:563) > [Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:336) > [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:312) > [Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1160) > [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:356) > [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:215) > [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:220) > [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:147) > [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:169) > [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:165) > [Host Controller] at java.security.AccessController.doPrivileged(Native Method) > [Host Controller] at javax.security.auth.Subject.doAs(Subject.java:422) > [Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) > [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:165) > [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298) > [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [Host Controller] at java.lang.Thread.run(Thread.java:745) > [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:320) > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:stop > { > "outcome" => "success", > "result" => "STOPPED" > } > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:kill > {"outcome" => "success"} > {noformat} > If the corresponding server-config resource is actually stopped, the operations fail because there is no resource at the operation's address. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 10:53:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 7 Nov 2014 10:53:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-229) server-config operations "leaks" to server's resources In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018352#comment-13018352 ] Brian Stansberry commented on WFCORE-229: ----------------------------------------- I'm pretty sure this isn't server-config stuff leaking. It's most likely in the ProxyControllerRegistration for server=server-one, which gets the start/stop handler registered. It seems like that handler is being provided for any "start" op for that registration *or it's children*, rather than only being provided for that registration. I'm not sure why though. > server-config operations "leaks" to server's resources > ------------------------------------------------------ > > Key: WFCORE-229 > URL: https://issues.jboss.org/browse/WFCORE-229 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Jeff Mesnil > Assignee: Brian Stansberry > > Start a regular domain > Any operations on server children with the same names that server-config operations (:start, :stop, :restart, :kill) are executed instead of being rejected because the actual resources at the operation address does not define them. > Examples: > {noformat} > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:start > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0158: Operation handler failed: java.util.NoSuchElementException: No child 'undertow' exists", > "rolled-back" => true > } > => > [Host Controller] 16:15:30,231 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 15) WFLYCTL0013: Operation ("restart") failed - address: ([ > [Host Controller] ("host" => "master"), > [Host Controller] ("server" => "server-one"), > [Host Controller] ("subsystem" => "undertow") > [Host Controller] ]) - failure description: "WFLYHC0047: Cannot restart server undertow as it is not currently started; it is STOPPED" > [Host Controller] 16:18:43,764 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("start") failed - address: ([ > [Host Controller] ("host" => "master"), > [Host Controller] ("server" => "server-one"), > [Host Controller] ("subsystem" => "undertow") > [Host Controller] ]): java.util.NoSuchElementException: No child 'undertow' exists > [Host Controller] at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:369) > [Host Controller] at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:299) > [Host Controller] at org.jboss.dmr.ModelNode.require(ModelNode.java:870) > [Host Controller] at org.jboss.as.host.controller.ManagedServerBootCmdFactory.(ManagedServerBootCmdFactory.java:93) > [Host Controller] at org.jboss.as.host.controller.ServerInventoryImpl.createBootFactory(ServerInventoryImpl.java:629) > [Host Controller] at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:200) > [Host Controller] at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:110) > [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:728) > [Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:563) > [Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:336) > [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:312) > [Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1160) > [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:356) > [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:215) > [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:220) > [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:147) > [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:169) > [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:165) > [Host Controller] at java.security.AccessController.doPrivileged(Native Method) > [Host Controller] at javax.security.auth.Subject.doAs(Subject.java:422) > [Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) > [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:165) > [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:298) > [Host Controller] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [Host Controller] at java.lang.Thread.run(Thread.java:745) > [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:320) > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:stop > { > "outcome" => "success", > "result" => "STOPPED" > } > [domain at localhost:9990 /] /host=master/server=server-one/subsystem=undertow:kill > {"outcome" => "success"} > {noformat} > If the corresponding server-config resource is actually stopped, the operations fail because there is no resource at the operation's address. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 11:22:29 2014 From: issues at jboss.org (Paul Benedict (JIRA)) Date: Fri, 7 Nov 2014 11:22:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4063) Namespace error in jboss-web_8_0.xsd In-Reply-To: References: Message-ID: Paul Benedict created WFLY-4063: ----------------------------------- Summary: Namespace error in jboss-web_8_0.xsd Key: WFLY-4063 URL: https://issues.jboss.org/browse/WFLY-4063 Project: WildFly Issue Type: Feature Request Components: EE Affects Versions: 8.1.0.Final Reporter: Paul Benedict Assignee: David Lloyd Priority: Minor I think there's an error in this XSD which prevents me from using the "javaee" elements you intend to import. First, the "javaee" namespace is declared as {{http://xmlns.jcp.org/xml/ns/javaee}} in the XML header, but then (surprisingly) the uses another namepace: {code} {code} I'm fairly confident this is wrong. It's importing under the old Java EE namespace -- not the new one which the header correctly declares. Hence, consumers are unable to get the "javaee" elements. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 11:24:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 7 Nov 2014 11:24:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-380) Namespace error in jboss-web_8_0.xsd In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar moved WFLY-4063 to JBMETA-380: ------------------------------------------ Project: JBoss Metadata (was: WildFly) Key: JBMETA-380 (was: WFLY-4063) Issue Type: Bug (was: Feature Request) Workflow: classic default workflow (was: GIT Pull Request workflow ) Affects Version/s: 8.0.0.Final (was: 8.1.0.Final) Component/s: web (was: EE) > Namespace error in jboss-web_8_0.xsd > ------------------------------------ > > Key: JBMETA-380 > URL: https://issues.jboss.org/browse/JBMETA-380 > Project: JBoss Metadata > Issue Type: Bug > Components: web > Affects Versions: 8.0.0.Final > Reporter: Paul Benedict > Assignee: David Lloyd > Priority: Minor > Labels: xsd > > I think there's an error in this XSD which prevents me from using the "javaee" elements you intend to import. > First, the "javaee" namespace is declared as {{http://xmlns.jcp.org/xml/ns/javaee}} in the XML header, but then (surprisingly) the uses another namepace: > {code} > > {code} > I'm fairly confident this is wrong. It's importing under the old Java EE namespace -- not the new one which the header correctly declares. Hence, consumers are unable to get the "javaee" elements. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 12:47:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 7 Nov 2014 12:47:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-230) Failure by ProcessController to launch a server vm is not logged In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-230: --------------------------------------- Summary: Failure by ProcessController to launch a server vm is not logged Key: WFCORE-230 URL: https://issues.jboss.org/browse/WFCORE-230 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha11 Reporter: Brian Stansberry Fix For: 1.0.0.CR1 In a domain configuration, if a server is associated with an incorrectly configurated jvm java-home (e.g. domain.xml -> server-groups -> jvm), it will fail silently (no error shown in logs). For example: ``` ``` -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 12:51:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 7 Nov 2014 12:51:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-231) It should be possible to specify the server-name and sasl-protocol on the connector In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-231: --------------------------------------- Summary: It should be possible to specify the server-name and sasl-protocol on the connector Key: WFCORE-231 URL: https://issues.jboss.org/browse/WFCORE-231 Project: WildFly Core Issue Type: Feature Request Components: Remoting Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha12 Also the default protocol needs to be 'remote' At the moment these two attributes are only defined on the endpoint but really each connector could be representing a different identity so it needs to be possible to specify these on the connector. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 13:05:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 7 Nov 2014 13:05:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2732) Injected EJB not available to MDB @PreDestroy methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018413#comment-13018413 ] RH Bugzilla Integration commented on WFLY-2732: ----------------------------------------------- Carlo de Wolf changed the Status of [bug 1103786|https://bugzilla.redhat.com/show_bug.cgi?id=1103786] from POST to MODIFIED > Injected EJB not available to MDB @PreDestroy methods > ----------------------------------------------------- > > Key: WFLY-2732 > URL: https://issues.jboss.org/browse/WFLY-2732 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 8.0.0.Final > > Attachments: MDBLifeCycleJAR.zip > > > MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed. > This was fixed in an RFE for Session Beans but does not seem to work for MDB. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 13:19:29 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 7 Nov 2014 13:19:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-620) Interval rule consequence actions not processed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-620: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Interval rule consequence actions not processed > ----------------------------------------------- > > Key: DROOLS-620 > URL: https://issues.jboss.org/browse/DROOLS-620 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta1 > Environment: MacBook Pro, OS X 10.9.5 > Reporter: Roger Lefebvre > Assignee: Mario Fusco > > Actions defined in the consequence of a rule with an defined interval (e.g. cron) are not processed by the system. Inserted facts, modified fields and pushed agenda groups are not consumed resulting in other rules not being fired. If you execute fireAllRules from code, it will then process the consequence actions. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 13:52:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 7 Nov 2014 13:52:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-230) Failure by ProcessController to launch a server vm is not logged In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018420#comment-13018420 ] Brian Stansberry commented on WFCORE-230: ----------------------------------------- DefaultJvmUtils is detecting this and throwing an exception on the HC, during execution of ManagedServer.ProcessAddTask. But ManagedServer.internalSetState is catching the exception and logging it at DEBUG. Simplest fix would be to change that log level to ERROR, but I'll need to check with Emanuel re: the thinking behind using debug there and in other spots in ManagedServer. > Failure by ProcessController to launch a server vm is not logged > ---------------------------------------------------------------- > > Key: WFCORE-230 > URL: https://issues.jboss.org/browse/WFCORE-230 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Fix For: 1.0.0.CR1 > > > In a domain configuration, if a server is associated with an incorrectly configurated jvm java-home (e.g. domain.xml -> server-groups -> jvm), it will fail silently (no error shown in logs). For example: > ``` > > > > > > ``` -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 13:52:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 7 Nov 2014 13:52:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-230) Failure by ProcessController to launch a server vm is not logged In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-230: --------------------------------------- Assignee: Brian Stansberry > Failure by ProcessController to launch a server vm is not logged > ---------------------------------------------------------------- > > Key: WFCORE-230 > URL: https://issues.jboss.org/browse/WFCORE-230 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.CR1 > > > In a domain configuration, if a server is associated with an incorrectly configurated jvm java-home (e.g. domain.xml -> server-groups -> jvm), it will fail silently (no error shown in logs). For example: > ``` > > > > > > ``` -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 13:52:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 7 Nov 2014 13:52:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-230) Failure by ProcessController to launch a server vm is not logged In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-230: ------------------------------------ Assignee: Emanuel Muckenhuber (was: Brian Stansberry) > Failure by ProcessController to launch a server vm is not logged > ---------------------------------------------------------------- > > Key: WFCORE-230 > URL: https://issues.jboss.org/browse/WFCORE-230 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 1.0.0.CR1 > > > In a domain configuration, if a server is associated with an incorrectly configurated jvm java-home (e.g. domain.xml -> server-groups -> jvm), it will fail silently (no error shown in logs). For example: > ``` > > > > > > ``` -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 14:00:31 2014 From: issues at jboss.org (Roger Lefebvre (JIRA)) Date: Fri, 7 Nov 2014 14:00:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-645) Accumulate returned fact causing NPE In-Reply-To: References: Message-ID: Roger Lefebvre created DROOLS-645: ------------------------------------- Summary: Accumulate returned fact causing NPE Key: DROOLS-645 URL: https://issues.jboss.org/browse/DROOLS-645 Project: Drools Issue Type: Bug Affects Versions: 6.2.0.Beta2 Environment: Mac OSX (maverick) Reporter: Roger Lefebvre Assignee: Mark Proctor The issue is discussed in https://groups.google.com/forum/?hl=en-GB#!topic/drools-usage/aZU5mXSgHMI. Here is the gist of it.... I changed the accumulator to the following and it worked: accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), $message:oldestRetry( $sm )) The previous approach was this: $message:StatusMessage() from accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), oldestRetry( $sm )) which I thought was the correct or acceptable syntax option. Is there something I have overlooked in the second one ("from"??). It does give me a StatusMessage object but it lacks the underlying properties to allow the subsequent modify to work. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 14:33:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 7 Nov 2014 14:33:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3872) Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018427#comment-13018427 ] Brian Stansberry commented on WFLY-3872: ---------------------------------------- This failed again: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=28794&buildTypeId=WildFlyCore_PullRequest_WildFlyCoreFullIntegration > Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn > -------------------------------------------------------------------------------------------- > > Key: WFLY-3872 > URL: https://issues.jboss.org/browse/WFLY-3872 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > Since https://github.com/wildfly/wildfly/pull/6660 was submitted, EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn is failing regularly. Not every time but very often. > Alessio, you mentioned seeing some error logging from XAResourceRecoveryImpl, but that's in the logs on successful runs as well, and occurs prior to the test as well. That's a period background task from the transaction manager trying to perform recovery of some previous transaction. I don't see why it would have any impact on this test. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 16:27:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 7 Nov 2014 16:27:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-232) Unclean shutdown of deployment scanner In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-232: --------------------------------------- Summary: Unclean shutdown of deployment scanner Key: WFCORE-232 URL: https://issues.jboss.org/browse/WFCORE-232 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha11 Reporter: Brian Stansberry I happened to see this in a testsuite log file: ``` 2014-11-07 02:59:41,808 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /opt/buildAgent/work/8feb0abb503148fe/testsuite/manualmode/target/deployment-test-bc636b67-df54-462d-9a13-3618a1755d3f threw Exception: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask at 146a4b2 rejected from java.util.concurrent.ScheduledThreadPoolExecutor at e6cbcd[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 3] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325) at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530) at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619) at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:669) at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:605) at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.deploy(DefaultDeploymentOperations.java:61) at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:449) at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:538) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) at org.jboss.threads.JBossThread.run(JBossThread.java:320) ``` DeploymentScannerService is calling stopScanner() on the scanner and then is shutting down the executor. But stopScanner does not wait for in progress tasks to complete, nor do the in-progress tasks recognize that shutdown is occurring and handle any problems differently (e.g. don't toss the above in the log.) Waiting for tasks to complete could be tricky, e.g. imagine this race: 1) Admin submits op to shutdown/reload, which has the controller lock and is now stopping services. 2) Scan job kicks off, finds changes and wants to modify the model, so the task is blocking waiting for the controller lock. Deadlock. Now, this may not be a problem, as server reload tells MSC to remove the root service on the way out (i.e. after the bit where it blocks for stability) and then MSC threads take over, allowing the op thread to continue and release the lock. The shutdown handler spawns a thread to call System.exit. But ^^^ is just a quick look, so be cautious! -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 16:33:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 7 Nov 2014 16:33:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-232) Unclean shutdown of deployment scanner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-232: ------------------------------------ Description: I happened to see this in a testsuite log file: {code} 2014-11-07 02:59:41,808 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /opt/buildAgent/work/8feb0abb503148fe/testsuite/manualmode/target/deployment-test-bc636b67-df54-462d-9a13-3618a1755d3f threw Exception: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask at 146a4b2 rejected from java.util.concurrent.ScheduledThreadPoolExecutor at e6cbcd[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 3] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325) at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530) at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619) at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:669) at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:605) at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.deploy(DefaultDeploymentOperations.java:61) at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:449) at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:538) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) at org.jboss.threads.JBossThread.run(JBossThread.java:320) {code} DeploymentScannerService is calling stopScanner() on the scanner and then is shutting down the executor. But stopScanner does not wait for in progress tasks to complete, nor do the in-progress tasks recognize that shutdown is occurring and handle any problems differently (e.g. don't toss the above in the log.) Waiting for tasks to complete could be tricky, e.g. imagine this race: 1) Admin submits op to shutdown/reload, which has the controller lock and is now stopping services. 2) Scan job kicks off, finds changes and wants to modify the model, so the task is blocking waiting for the controller lock. Deadlock. Now, this may not be a problem, as server reload tells MSC to remove the root service on the way out (i.e. after the bit where it blocks for stability) and then MSC threads take over, allowing the op thread to continue and release the lock. The shutdown handler spawns a thread to call System.exit. But ^^^ is just a quick look, so be cautious! was: I happened to see this in a testsuite log file: ``` 2014-11-07 02:59:41,808 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /opt/buildAgent/work/8feb0abb503148fe/testsuite/manualmode/target/deployment-test-bc636b67-df54-462d-9a13-3618a1755d3f threw Exception: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask at 146a4b2 rejected from java.util.concurrent.ScheduledThreadPoolExecutor at e6cbcd[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 3] at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325) at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530) at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619) at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:669) at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:605) at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.deploy(DefaultDeploymentOperations.java:61) at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:449) at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:538) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) at org.jboss.threads.JBossThread.run(JBossThread.java:320) ``` DeploymentScannerService is calling stopScanner() on the scanner and then is shutting down the executor. But stopScanner does not wait for in progress tasks to complete, nor do the in-progress tasks recognize that shutdown is occurring and handle any problems differently (e.g. don't toss the above in the log.) Waiting for tasks to complete could be tricky, e.g. imagine this race: 1) Admin submits op to shutdown/reload, which has the controller lock and is now stopping services. 2) Scan job kicks off, finds changes and wants to modify the model, so the task is blocking waiting for the controller lock. Deadlock. Now, this may not be a problem, as server reload tells MSC to remove the root service on the way out (i.e. after the bit where it blocks for stability) and then MSC threads take over, allowing the op thread to continue and release the lock. The shutdown handler spawns a thread to call System.exit. But ^^^ is just a quick look, so be cautious! > Unclean shutdown of deployment scanner > -------------------------------------- > > Key: WFCORE-232 > URL: https://issues.jboss.org/browse/WFCORE-232 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > > I happened to see this in a testsuite log file: > {code} > 2014-11-07 02:59:41,808 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0012: Scan of /opt/buildAgent/work/8feb0abb503148fe/testsuite/manualmode/target/deployment-test-bc636b67-df54-462d-9a13-3618a1755d3f threw Exception: java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask at 146a4b2 rejected from java.util.concurrent.ScheduledThreadPoolExecutor at e6cbcd[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 3] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:325) > at java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:530) > at java.util.concurrent.ScheduledThreadPoolExecutor.execute(ScheduledThreadPoolExecutor.java:619) > at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:669) > at org.jboss.as.controller.ModelControllerImpl$3.executeAsync(ModelControllerImpl.java:605) > at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.deploy(DefaultDeploymentOperations.java:61) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:449) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$UndeployScanRunnable.run(FileSystemDeploymentService.java:538) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} > DeploymentScannerService is calling stopScanner() on the scanner and then is shutting down the executor. But stopScanner does not wait for in progress tasks to complete, nor do the in-progress tasks recognize that shutdown is occurring and handle any problems differently (e.g. don't toss the above in the log.) > Waiting for tasks to complete could be tricky, e.g. imagine this race: > 1) Admin submits op to shutdown/reload, which has the controller lock and is now stopping services. > 2) Scan job kicks off, finds changes and wants to modify the model, so the task is blocking waiting for the controller lock. > Deadlock. > Now, this may not be a problem, as server reload tells MSC to remove the root service on the way out (i.e. after the bit where it blocks for stability) and then MSC threads take over, allowing the op thread to continue and release the lock. The shutdown handler spawns a thread to call System.exit. > But ^^^ is just a quick look, so be cautious! -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 16:41:29 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Fri, 7 Nov 2014 16:41:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-202) Deadlock when shutdown Wildfly server during CLI client connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Loubyansky reassigned WFCORE-202: ---------------------------------------- Assignee: Alexey Loubyansky (was: Chao Wang) > Deadlock when shutdown Wildfly server during CLI client connection > ------------------------------------------------------------------ > > Key: WFCORE-202 > URL: https://issues.jboss.org/browse/WFCORE-202 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha10 > Reporter: Chao Wang > Assignee: Alexey Loubyansky > > Creating upstream issue as the same deadlock can be found in WFLY. > Descirption as comment 5 in [BZ1142538|https://bugzilla.redhat.com/show_bug.cgi?id=1142538] > {noformat} > The following deadlock still exists. > Steps to Reproduce: > 1. Prepare a running EAP instance with secured management port - optionally in VM > 2. Execute export JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" > 3. In the same terminal, execute "bin/jboss-cli.sh --connect --controller=$EAP_IP --user=admin --password=password ':read-resource'" > 4. From yet another terminal, execute "jdb -attach localhost:8787" > 5. In JDB: > 5.a. Create breakpoint: "stop in org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 5.b. Resume all threads: "resume" > 5.c. [Execute five times] Wait until breakpoint is hit and execute "resume". Either set timeout or be fast so that timeout does not occur first > 6. Execute "kill -9 $EAP_PID" - optionally in VM > 7. In JDB: > 8.a. Remove breakpoint: "clear org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 8.b. Resume all threads: "resume" > 9. Now dump the stack trace of jboss-cli.sh: "kill -3 $JBOSS_CLI_PID" > Found one Java-level deadlock: > ============================= > "Remoting "cli-client" read-1": > waiting to lock monitor 0x00007ff9c829b558 (object 0x0000000783433408, a java.lang.String), > which is held by "main" > "main": > waiting to lock monitor 0x00007ff9c8333c48 (object 0x00000007851ae6e0, a java.util.ArrayDeque), > which is held by "Remoting "cli-client" read-1" > Java stack information for the threads listed above: > =================================================== > "Remoting "cli-client" read-1": > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:286) > - waiting to lock <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:269) > at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54) > at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:532) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) > at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:392) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:109) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:81) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:183) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.nio.NioHandle.run(NioHandle.java:90) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:198) > "main": > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:361) > - waiting to lock <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.connectionOpened(FutureManagementChannel.java:217) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:78) > - locked <0x0000000784978a00> (a org.jboss.as.protocol.ProtocolConnectionManager) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160) > - locked <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:123) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:98) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:980) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:841) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:817) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:250) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > 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:483) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > {noformat} > It can be easily reproduce with Eclipse as: > {noformat} > 1 start Wildfly > 2 uncomment "JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" in jboss-cli.sh and connect to server > 3 add two break points at > CLIModelControllerClient$ChannelCloseHandler [line: 285] - handleClose(Channel, IOException) > RemoteConnectionChannel [line: 360] - receiveMessage(Receiver) > 4 connect to 8787 from eclipse debug > 5 shutdown Wildfly > A deadlock between "main" and "cli-client" is in Eclipse debug stack. > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 17:36:34 2014 From: issues at jboss.org (Roger Lefebvre (JIRA)) Date: Fri, 7 Nov 2014 17:36:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-645) Accumulate returned fact causing NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Lefebvre updated DROOLS-645: ---------------------------------- Attachment: RetryOldestCallTimeAccumulateFunction.java > Accumulate returned fact causing NPE > ------------------------------------ > > Key: DROOLS-645 > URL: https://issues.jboss.org/browse/DROOLS-645 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta2 > Environment: Mac OSX (maverick) > Reporter: Roger Lefebvre > Assignee: Mark Proctor > Attachments: RetryOldestCallTimeAccumulateFunction.java > > > The issue is discussed in https://groups.google.com/forum/?hl=en-GB#!topic/drools-usage/aZU5mXSgHMI. > Here is the gist of it.... > I changed the accumulator to the following and it worked: > accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), $message:oldestRetry( $sm )) > The previous approach was this: > $message:StatusMessage() from accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), oldestRetry( $sm )) > which I thought was the correct or acceptable syntax option. Is there something I have overlooked in the second one ("from"??). It does give me a StatusMessage object but it lacks the underlying properties to allow the subsequent modify to work. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 7 17:37:29 2014 From: issues at jboss.org (Roger Lefebvre (JIRA)) Date: Fri, 7 Nov 2014 17:37:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-645) Accumulate returned fact causing NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Lefebvre updated DROOLS-645: ---------------------------------- Attachment: RetryOldestCallTimeAccumulateFunction.java Sorting accumulate function returns first item in list. > Accumulate returned fact causing NPE > ------------------------------------ > > Key: DROOLS-645 > URL: https://issues.jboss.org/browse/DROOLS-645 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta2 > Environment: Mac OSX (maverick) > Reporter: Roger Lefebvre > Assignee: Mark Proctor > Attachments: RetryOldestCallTimeAccumulateFunction.java, RetryOldestCallTimeAccumulateFunction.java > > > The issue is discussed in https://groups.google.com/forum/?hl=en-GB#!topic/drools-usage/aZU5mXSgHMI. > Here is the gist of it.... > I changed the accumulator to the following and it worked: > accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), $message:oldestRetry( $sm )) > The previous approach was this: > $message:StatusMessage() from accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), oldestRetry( $sm )) > which I thought was the correct or acceptable syntax option. Is there something I have overlooked in the second one ("from"??). It does give me a StatusMessage object but it lacks the underlying properties to allow the subsequent modify to work. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 08:39:30 2014 From: issues at jboss.org (Georgy Go (JIRA)) Date: Sat, 8 Nov 2014 08:39:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4064) Web-fragments of Servlet 3 API doesn't work in WildFly In-Reply-To: References: Message-ID: Georgy Go created WFLY-4064: ------------------------------- Summary: Web-fragments of Servlet 3 API doesn't work in WildFly Key: WFLY-4064 URL: https://issues.jboss.org/browse/WFLY-4064 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 8.1.0.Final Reporter: Georgy Go Assignee: Stuart Douglas The same project with web-fragments works fine in Tomcat 8 and doesn't in WildFly 8.1.0.Final. The problem is registred servlet unaccessable from it's path, failes with "Not Found" error. Because it's works fine in Tomcat, I think it's bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 08:39:30 2014 From: issues at jboss.org (Georgy Go (JIRA)) Date: Sat, 8 Nov 2014 08:39:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4064) Web-fragments of Servlet 3 API doesn't work in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Georgy Go updated WFLY-4064: ---------------------------- Component/s: Web (JBoss Web) > Web-fragments of Servlet 3 API doesn't work in WildFly > ------------------------------------------------------ > > Key: WFLY-4064 > URL: https://issues.jboss.org/browse/WFLY-4064 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web), Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Georgy Go > Assignee: Stuart Douglas > > The same project with web-fragments works fine in Tomcat 8 and doesn't in WildFly 8.1.0.Final. > The problem is registred servlet unaccessable from it's path, failes with "Not Found" error. > Because it's works fine in Tomcat, I think it's bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 10:16:29 2014 From: issues at jboss.org (Georgy Go (JIRA)) Date: Sat, 8 Nov 2014 10:16:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4064) Web-fragments of Servlet 3 API doesn't work in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Georgy Go updated WFLY-4064: ---------------------------- Priority: Blocker (was: Major) > Web-fragments of Servlet 3 API doesn't work in WildFly > ------------------------------------------------------ > > Key: WFLY-4064 > URL: https://issues.jboss.org/browse/WFLY-4064 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web), Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Georgy Go > Assignee: Stuart Douglas > Priority: Blocker > > The same project with web-fragments works fine in Tomcat 8 and doesn't in WildFly 8.1.0.Final. > The problem is registred servlet unaccessable from it's path, failes with "Not Found" error. > Because it's works fine in Tomcat, I think it's bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 11:05:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 8 Nov 2014 11:05:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-97) Object value passed to JBossLogManagerProvider.putMdc(String, Object) should be returned from getMdc(final String) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated JBLOGGING-97: ----------------------------------- Fix Version/s: (was: 3.1.5.GA) > Object value passed to JBossLogManagerProvider.putMdc(String, Object) should be returned from getMdc(final String) > ------------------------------------------------------------------------------------------------------------------ > > Key: JBLOGGING-97 > URL: https://issues.jboss.org/browse/JBLOGGING-97 > Project: JBoss Logging > Issue Type: Bug > Components: slf4j-jboss-logmanager > Affects Versions: 3.1.3.GA > Reporter: Scott Marlow > Assignee: James Perkins > Priority: Blocker > > Change JBossLogManagerProvider.putMdc(final String key, final Object value) to call MDC.put(key, value) instead of MDC.put(key, String.valueOf(value)) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 11:08:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 8 Nov 2014 11:08:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-65) JBoss Logging fails to support log4j-over-slf4j In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated JBLOGGING-65: ----------------------------------- Fix Version/s: 3.0.0.GA > JBoss Logging fails to support log4j-over-slf4j > ----------------------------------------------- > > Key: JBLOGGING-65 > URL: https://issues.jboss.org/browse/JBLOGGING-65 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.0.0.Beta5-jboss-logging > Reporter: Jeff Ramsdale > Assignee: David Lloyd > Priority: Critical > Fix For: 3.0.0.GA > > > org.jboss.logging.LoggerProviders tests for the existence of org.apache.log4j.LogManager and if it discovers it assumes Log4j is in use. This is incorrect in the scenario where log4j events are routed to slf4j for eventual routing to another logging engine (a very common use case). This engine may be Logback, but may not. Therefore, the test for whether slf4j is in use is not whether Logback is in the classpath (Logback is AN implementation of slf4j, not THE implementation...), but whether org.slf4j.impl.StaticLoggerBinder is. There should be no attempt to detect Logback itself. JBoss Logging cannot tell through simply loading org.apache.log4j.LogManager whether this class is provided by log4j or by log4j-over-slf4j so cannot use this class to detect log4j use. To clarify, the logic should be: > 1) If org.slf4j.impl.StaticLoggerBinder is available, use slf4j. > 2) If org.apache.log4j.LogManager (but not StaticLoggerBinder) is available, use log4j. > 3) Otherwise use java.util.logging -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 11:08:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 8 Nov 2014 11:08:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-49) Relocate @Messages and @MessageBundle to i18n package In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated JBLOGGING-49: ----------------------------------- Fix Version/s: 3.0.0.GA > Relocate @Messages and @MessageBundle to i18n package > ----------------------------------------------------- > > Key: JBLOGGING-49 > URL: https://issues.jboss.org/browse/JBLOGGING-49 > Project: JBoss Logging > Issue Type: Feature Request > Affects Versions: 3.0.0.Beta4-jboss-logging > Reporter: Dan Allen > Assignee: David Lloyd > Fix For: 3.0.0.GA > > > The message bundle facility in JBoss Logging is generally useful. In fact, we are planning on using it as a foundation for comprehensive i18n support in Seam 3. However, developers are going to be very standoff-ish if they have to import the @Messages and @MessageBundle annotations from a logging package (org.jboss.logging). I suggest moving them to the org.jboss.i18n package, though keeping it part of the JBoss Logging project since that will remain a foundation library and to stick to 1 JAR. > Actual: > org.jboss.logging.Messages > org.jboss.logging.MessageBundle > Proposed: > org.jboss.i18n.Messages > org.jboss.i18n.MessageBundle > Relocate any other types as necessary. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 11:09:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 8 Nov 2014 11:09:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-51) jboss-logging-spi in OSGI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed JBLOGGING-51. ---------------------------------- > jboss-logging-spi in OSGI > ------------------------- > > Key: JBLOGGING-51 > URL: https://issues.jboss.org/browse/JBLOGGING-51 > Project: JBoss Logging > Issue Type: Feature Request > Environment: felix > Reporter: Luca Stancapiano > Assignee: David Lloyd > > I'ld like jboss-logging-spi be a OSGI bundle so it can be installed in all OSGI repositories. Actually I tested it with felix. To do it it is enough add this plugin configuration in the pom.xml: > > > org.apache.felix > maven-bundle-plugin > 2.1.0 > true > > > http://community.jboss.org/wiki/JBossCommonProject > > ${project.groupId}.*;version=${project.version};-split-package:=error > > > > > and modify the row from 'jar' to 'bundle' so: > bundle -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 11:09:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 8 Nov 2014 11:09:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-52) Use of system property for proxy generation setting is too inflexible In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed JBLOGGING-52. ---------------------------------- > Use of system property for proxy generation setting is too inflexible > --------------------------------------------------------------------- > > Key: JBLOGGING-52 > URL: https://issues.jboss.org/browse/JBLOGGING-52 > Project: JBoss Logging > Issue Type: Bug > Components: jboss-logging-spi > Affects Versions: 3.0.0.Beta4-jboss-logging > Reporter: Dan Allen > Assignee: James Perkins > > JBoss Logging uses a system property to configure whether or not proxies are generated for type-safe loggers. This approach is very inflexible. > The main issue is that the value of this system property is being cached too aggressively. In CDI extensions, we are forced to use a static code block to set the property so it is assigned early enough that JBoss Logging caches the correct value. However, with multiple extensions loading in a non-deterministic order, we end up having to put this static block in multiple places. [1] > We need a better way to apply this setting. Perhaps a static method on a configuration API to assign the value before any logging takes place. > [1] https://github.com/seam/solder/blob/master/impl/src/main/java/org/jboss/seam/solder/log/LoggerExtension.java > https://github.com/seam/servlet/blob/master/impl/src/main/java/org/jboss/seam/servlet/ServletExtension.java -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 11:10:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 8 Nov 2014 11:10:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-84) Configurable default Locale for Logger#getMessageLogger() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed JBLOGGING-84. ---------------------------------- > Configurable default Locale for Logger#getMessageLogger() > --------------------------------------------------------- > > Key: JBLOGGING-84 > URL: https://issues.jboss.org/browse/JBLOGGING-84 > Project: JBoss Logging > Issue Type: Feature Request > Reporter: Michael Locher > Assignee: David Lloyd > > Please make the Locale for org.jboss.logging.Logger#getMessageLogger configurable (e.g. via a system property). > Use Case: > Having different locales for 'application code' which is deployed in JBAPP (specified as JVM default at startup and available via Locale.getDefault()) and the locale for logging of JBAPP. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 11:11:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 8 Nov 2014 11:11:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-63) Hexadecimal in log message error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed JBLOGGING-63. ---------------------------------- > Hexadecimal in log message error > -------------------------------- > > Key: JBLOGGING-63 > URL: https://issues.jboss.org/browse/JBLOGGING-63 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.0.0.Beta5-jboss-logging > Reporter: Galder Zamarre?o > Assignee: David Lloyd > > The following code fails with JBoss Logging: > String message = "Invalid magic number. Expected %#x and received %#x"; > log.invalidMagicNumber(message, HotRodConstants.RESPONSE_MAGIC, magic); > With: > java.util.IllegalFormatConversionException: x != java.lang.String > at java.util.Formatter$FormatSpecifier.failConversion(Formatter.java:3999) > at java.util.Formatter$FormatSpecifier.printInteger(Formatter.java:2709) > at java.util.Formatter$FormatSpecifier.print(Formatter.java:2661) > at java.util.Formatter.format(Formatter.java:2433) > at java.util.Formatter.format(Formatter.java:2367) > at java.lang.String.format(String.java:2769) > at org.jboss.logging.Log4jLogger.doLogf(Log4jLogger.java:48) > at org.jboss.logging.Logger.logf(Logger.java:2130) > at org.infinispan.client.hotrod.logging.Log_$logger.invalidMagicNumber(Log_$logger.java:820) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:106) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:70) > at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:49) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:62) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:201) > at org.infinispan.CacheSupport.put(CacheSupport.java:51) > at org.infinispan.client.hotrod.ServerErrorTest.testErrorWhileDoingPut(ServerErrorTest.java:87) > Whereas the following works: > log.info(String.format("Invalid magic number. Expected %#x and received %#x", HotRodConstants.RESPONSE_MAGIC, magic)); > And prints: > 2011-05-18 14:58:43,929 INFO [HotRodOperation] (main) Invalid magic number. Expected 0xa1 and received 0xa1 > It seems like JBoss Logging is doing something that avoids hexadecimals to be shown in the same way as you'd do with String.format(). > Maybe JBoss Logging is expecting something different here? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 11:11:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 8 Nov 2014 11:11:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-66) Class org.jboss.logging.JDKLevel causes classloader leaks on undeployment of projects using jboss-logging in their war In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed JBLOGGING-66. ---------------------------------- > Class org.jboss.logging.JDKLevel causes classloader leaks on undeployment of projects using jboss-logging in their war > ---------------------------------------------------------------------------------------------------------------------- > > Key: JBLOGGING-66 > URL: https://issues.jboss.org/browse/JBLOGGING-66 > Project: JBoss Logging > Issue Type: Bug > Environment: java version "1.6.0_22" > OpenJDK Runtime Environment (IcedTea6 1.10.2) (fedora-58.1.10.2.fc15-x86_64) > OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode) > x64 Core 2 Duo laptop with 4GB RAM > Reporter: Craig Ringer > Assignee: David Lloyd > > I've been chasing classloader leaks that've been causing my app to fail to redeploy after a few iterations. A bit of digging using jmap and jhat has begun to strongly suggest that JBoss Logging is the problem. > The issue is exactly the same as the one used as an example in this article on tracing classloader leaks: > http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java > Specifically, org.jboss.logging.JDKLevel extends java.util.logging.Level . Unfortunately, java.util.logging.Level keeps a static array of all known logging levels. If JBoss Logging was deployed as part of an application war, that means there's a reference kept from an application server class (java.util.logging.Level) to a client application class (org.jboss.logging.JDKLevel). This keeps the whole reference chain intact and stops the application classloader from being destroyed. > This is a problem on Glassfish 3.1, because JBoss Logging isn't included in the application server so it must be deployed by applications if they want to use things like JBoss Seam. > It should be possible to add jboss-logging to glassfish/domains/domain1/lib to work around this, by making sure that org.jboss.logging.JDKLevel is loaded by the appserver classloader not the classloader of the deployed application. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 11:11:31 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 8 Nov 2014 11:11:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-78) SMTPAppender Not sending mails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed JBLOGGING-78. ---------------------------------- > SMTPAppender Not sending mails > ------------------------------ > > Key: JBLOGGING-78 > URL: https://issues.jboss.org/browse/JBLOGGING-78 > Project: JBoss Logging > Issue Type: Task > Components: jboss-logging-log4j > Environment: JDK1.6 > Reporter: Nisha Suresh > Assignee: David Lloyd > > I have enabled the SMTPAppender for threshold level "ERROR". After that when an error occurs in the application the server.log is showing like: > 2012-01-27 14:20:58,565 FINE [javax.activation] (http-127.0.0.1-8090-1) MailcapCommandMap: createDataContentHandler for text/plain > 2012-01-27 14:20:58,565 FINE [javax.activation] (http-127.0.0.1-8090-1) search DB #1 > 2012-01-27 14:20:58,565 FINE [javax.activation] (http-127.0.0.1-8090-1) got content-handler > 2012-01-27 14:20:58,565 FINE [javax.activation] (http-127.0.0.1-8090-1) class com.sun.mail.handlers.text_plain > No other mail sending errors are shown. What does this log actually means? > Why the mails are not getting send? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 11:12:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 8 Nov 2014 11:12:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-69) null log handle in Quartz job In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed JBLOGGING-69. ---------------------------------- > null log handle in Quartz job > ----------------------------- > > Key: JBLOGGING-69 > URL: https://issues.jboss.org/browse/JBLOGGING-69 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.0.0.GA > Reporter: JEE 4 Hire > Assignee: David Lloyd > Labels: quartz > > The instance of org.jboss.logging.Logger does not work inside HelloJob quartz job. > The log handle is null when using: > @Inject > private Logger log; > For more info: > http://seamframework.org/Community/NullEntityManagerInQuartzJob -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 11:12:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 8 Nov 2014 11:12:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-55) NPE in FileAppender$Helper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed JBLOGGING-55. ---------------------------------- > NPE in FileAppender$Helper > -------------------------- > > Key: JBLOGGING-55 > URL: https://issues.jboss.org/browse/JBLOGGING-55 > Project: JBoss Logging > Issue Type: Bug > Reporter: Ondrej Zizka > Assignee: David Lloyd > Attachments: log4j.xml > > > When you set the file="..." to just a file, i.e. file="foobar.log", > then you get a NPE at line > if (!dir.exists()) { > probably because > dir = new File(filename.trim()).getParentFile(); > returns null. > I'd expect the appender to write to a file in new File( new File(System.getProperty("user.dir")), filename.trim() ). > package org.jboss.logging.appender; > import java.io.File; > import java.net.MalformedURLException; > import java.net.URL; > import org.apache.log4j.helpers.LogLog; > public class FileAppender$Helper > { > public static void makePath(String filename) > { > File dir; > try > { > URL url = new URL(filename.trim()); > dir = new File(url.getFile()).getParentFile(); > } > catch (MalformedURLException e) { > dir = new File(filename.trim()).getParentFile(); > } > if (!dir.exists()) { > boolean success = dir.mkdirs(); > if (!success) > LogLog.error("Failed to create directory structure: " + dir); > } > } > } -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 14:11:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Sat, 8 Nov 2014 14:11:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4064) Web-fragments of Servlet 3 API doesn't work in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018469#comment-13018469 ] Tomaz Cerar commented on WFLY-4064: ----------------------------------- Can you provide simple reproducer app so we can test this. > Web-fragments of Servlet 3 API doesn't work in WildFly > ------------------------------------------------------ > > Key: WFLY-4064 > URL: https://issues.jboss.org/browse/WFLY-4064 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web), Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Georgy Go > Assignee: Stuart Douglas > Priority: Blocker > > The same project with web-fragments works fine in Tomcat 8 and doesn't in WildFly 8.1.0.Final. > The problem is registred servlet unaccessable from it's path, failes with "Not Found" error. > Because it's works fine in Tomcat, I think it's bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 15:37:30 2014 From: issues at jboss.org (Georgy Go (JIRA)) Date: Sat, 8 Nov 2014 15:37:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4064) Web-fragments of Servlet 3 API doesn't work in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Georgy Go updated WFLY-4064: ---------------------------- Attachment: test.zip "Station.war" is war, "Kernel.jar" is web fragment. ReadyToRun.war is the same war with "Kernel.jar" already plugged in. > Web-fragments of Servlet 3 API doesn't work in WildFly > ------------------------------------------------------ > > Key: WFLY-4064 > URL: https://issues.jboss.org/browse/WFLY-4064 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web), Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Georgy Go > Assignee: Stuart Douglas > Priority: Blocker > Attachments: test.zip > > > The same project with web-fragments works fine in Tomcat 8 and doesn't in WildFly 8.1.0.Final. > The problem is registred servlet unaccessable from it's path, failes with "Not Found" error. > Because it's works fine in Tomcat, I think it's bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 15:40:30 2014 From: issues at jboss.org (Georgy Go (JIRA)) Date: Sat, 8 Nov 2014 15:40:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4064) Web-fragments of Servlet 3 API doesn't work in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018471#comment-13018471 ] Georgy Go edited comment on WFLY-4064 at 11/8/14 3:39 PM: ---------------------------------------------------------- "Station.war" is war, "Kernel.jar" is web fragment. ReadyToRun.war is the same war with "Kernel.jar" already plugged in. Run it on Tomcat and follow /tester link. You'll see "QQ" welcome message. Run it on WildFly and you will get "Not found" instead. was (Author: wilddev): "Station.war" is war, "Kernel.jar" is web fragment. ReadyToRun.war is the same war with "Kernel.jar" already plugged in. > Web-fragments of Servlet 3 API doesn't work in WildFly > ------------------------------------------------------ > > Key: WFLY-4064 > URL: https://issues.jboss.org/browse/WFLY-4064 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web), Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Georgy Go > Assignee: Stuart Douglas > Priority: Blocker > Attachments: test.zip > > > The same project with web-fragments works fine in Tomcat 8 and doesn't in WildFly 8.1.0.Final. > The problem is registred servlet unaccessable from it's path, failes with "Not Found" error. > Because it's works fine in Tomcat, I think it's bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 8 16:15:32 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Sat, 8 Nov 2014 16:15:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4064) Web-fragments of Servlet 3 API doesn't work in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-4064: ------------------------------ Priority: Major (was: Blocker) > Web-fragments of Servlet 3 API doesn't work in WildFly > ------------------------------------------------------ > > Key: WFLY-4064 > URL: https://issues.jboss.org/browse/WFLY-4064 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web), Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Georgy Go > Assignee: Stuart Douglas > Attachments: test.zip > > > The same project with web-fragments works fine in Tomcat 8 and doesn't in WildFly 8.1.0.Final. > The problem is registred servlet unaccessable from it's path, failes with "Not Found" error. > Because it's works fine in Tomcat, I think it's bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 08:46:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 08:46:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-233) Subsystem ordering is lost during marshalling In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-233: --------------------------------------- Summary: Subsystem ordering is lost during marshalling Key: WFCORE-233 URL: https://issues.jboss.org/browse/WFCORE-233 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha11 Reporter: Brian Stansberry Priority: Blocker Fix For: 1.0.0.Beta1 When standalone.xml gets persisted following some post-boot change, the original ordering of subsystems is lost. We don't want to change config files in this way. I don't recall how we retained the original subsystem ordering with parallel boot, but something there has broken. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 09:04:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 09:04:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-233) Subsystem ordering is lost during marshalling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018473#comment-13018473 ] Brian Stansberry commented on WFCORE-233: ----------------------------------------- AS7-2561 is the original issue for getting this correct. This was the solution: https://github.com/wildfly/wildfly/pull/610/files That code is still there. > Subsystem ordering is lost during marshalling > --------------------------------------------- > > Key: WFCORE-233 > URL: https://issues.jboss.org/browse/WFCORE-233 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Priority: Blocker > Fix For: 1.0.0.Beta1 > > > When standalone.xml gets persisted following some post-boot change, the original ordering of subsystems is lost. We don't want to change config files in this way. > I don't recall how we retained the original subsystem ordering with parallel boot, but something there has broken. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 10:52:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 10:52:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-233) Subsystem ordering is lost during marshalling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-233: ------------------------------------ Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Beta1) > Subsystem ordering is lost during marshalling > --------------------------------------------- > > Key: WFCORE-233 > URL: https://issues.jboss.org/browse/WFCORE-233 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Priority: Blocker > Fix For: 1.0.0.Alpha12 > > > When standalone.xml gets persisted following some post-boot change, the original ordering of subsystems is lost. We don't want to change config files in this way. > I don't recall how we retained the original subsystem ordering with parallel boot, but something there has broken. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 11:12:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 11:12:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-234) Inconsistent synchronization in ConfigurationFile In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-234: --------------------------------------- Summary: Inconsistent synchronization in ConfigurationFile Key: WFCORE-234 URL: https://issues.jboss.org/browse/WFCORE-234 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha11 Reporter: Brian Stansberry Fix For: 1.0.0.CR1 ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir. The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot. The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 11:23:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 11:23:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-235) Inconsistent synchronization in ConfigurationFile In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-235: --------------------------------------- Summary: Inconsistent synchronization in ConfigurationFile Key: WFCORE-235 URL: https://issues.jboss.org/browse/WFCORE-235 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha11 Reporter: Brian Stansberry Fix For: 1.0.0.CR1 ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir. The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot. The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 11:24:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 11:24:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-235) Inconsistent synchronization in ConfigurationFile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry closed WFCORE-235. ----------------------------------- Fix Version/s: (was: 1.0.0.CR1) Resolution: Duplicate Issue > Inconsistent synchronization in ConfigurationFile > ------------------------------------------------- > > Key: WFCORE-235 > URL: https://issues.jboss.org/browse/WFCORE-235 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > > ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir. > The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot. > The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 15:09:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 15:09:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3872) Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reopened WFLY-3872: ------------------------------------ Another failure, so I'm re-opening: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=29064&buildTypeId=WildFlyCore_PullRequest_WildFlyCoreFullIntegration I'm quite certain I also saw another one on some run in the last few days. > Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn > -------------------------------------------------------------------------------------------- > > Key: WFLY-3872 > URL: https://issues.jboss.org/browse/WFLY-3872 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > Since https://github.com/wildfly/wildfly/pull/6660 was submitted, EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn is failing regularly. Not every time but very often. > Alessio, you mentioned seeing some error logging from XAResourceRecoveryImpl, but that's in the logs on successful runs as well, and occurs prior to the test as well. That's a period background task from the transaction manager trying to perform recovery of some previous transaction. I don't see why it would have any impact on this test. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 16:13:30 2014 From: issues at jboss.org (Frank Langelage (JIRA)) Date: Sun, 9 Nov 2014 16:13:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4065) Warning about private module use issued twice In-Reply-To: References: Message-ID: Frank Langelage created WFLY-4065: ------------------------------------- Summary: Warning about private module use issued twice Key: WFLY-4065 URL: https://issues.jboss.org/browse/WFLY-4065 Project: WildFly Issue Type: Bug Components: Server Affects Versions: 9.0.0.Beta1 Reporter: Frank Langelage Assignee: Jason Greene Priority: Minor My web app is using some modules of WildFly AS which are not public. The warning about using private modules is issued twice for every module: 09.11. 22:07:34,088 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. 09.11. 22:07:34,090 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. 09.11. 22:07:34,092 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. 09.11. 22:07:34,094 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 17:00:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Sun, 9 Nov 2014 17:00:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4065) Warning about private module use issued twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018483#comment-13018483 ] Tomaz Cerar commented on WFLY-4065: ----------------------------------- What version is this? Current master with jboss-modules 1.4? > Warning about private module use issued twice > --------------------------------------------- > > Key: WFLY-4065 > URL: https://issues.jboss.org/browse/WFLY-4065 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 9.0.0.Beta1 > Reporter: Frank Langelage > Assignee: Jason Greene > Priority: Minor > > My web app is using some modules of WildFly AS which are not public. > The warning about using private modules is issued twice for every module: > 09.11. 22:07:34,088 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,090 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,092 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,094 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 17:27:29 2014 From: issues at jboss.org (Frank Langelage (JIRA)) Date: Sun, 9 Nov 2014 17:27:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4065) Warning about private module use issued twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018485#comment-13018485 ] Frank Langelage commented on WFLY-4065: --------------------------------------- Yes, it's current master based on WildFly Core 1.0.0.Alpha11 including jboss-modules 1.4.0.Beta1. > Warning about private module use issued twice > --------------------------------------------- > > Key: WFLY-4065 > URL: https://issues.jboss.org/browse/WFLY-4065 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 9.0.0.Beta1 > Reporter: Frank Langelage > Assignee: Jason Greene > Priority: Minor > > My web app is using some modules of WildFly AS which are not public. > The warning about using private modules is issued twice for every module: > 09.11. 22:07:34,088 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,090 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,092 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,094 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:33 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-231) It should be possible to specify the server-name and sasl-protocol on the connector In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-231: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > It should be possible to specify the server-name and sasl-protocol on the connector > ----------------------------------------------------------------------------------- > > Key: WFCORE-231 > URL: https://issues.jboss.org/browse/WFCORE-231 > Project: WildFly Core > Issue Type: Feature Request > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > > Also the default protocol needs to be 'remote' > At the moment these two attributes are only defined on the endpoint but really each connector could be representing a different identity so it needs to be possible to specify these on the connector. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:33 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-228) standalone.bat very slow In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-228: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > standalone.bat very slow > ------------------------ > > Key: WFCORE-228 > URL: https://issues.jboss.org/browse/WFCORE-228 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Reporter: Philippe Marschall > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha13 > > > With a plain WildFly AS downloaded and executing {code}standalone.bat{code} we see about two to three seconds spent in this loop: > {code} > rem Setup directories, note directories with spaces do not work > set "CONSOLIDATED_OPTS=%JAVA_OPTS% %SERVER_OPTS%" > :DIRLOOP > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.base.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_BASE_DIR=%%~fi" > ) > ) > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.config.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_CONFIG_DIR=%%~fi" > ) > ) > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.log.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_LOG_DIR=%%~fi" > ) > ) > for /f "tokens=1* delims= " %%i IN ("%CONSOLIDATED_OPTS%") DO ( > if %%i == "" ( > goto ENDDIRLOOP > ) else ( > set CONSOLIDATED_OPTS=%%j > GOTO DIRLOOP > ) > ) > :ENDDIRLOOP > {code} > It does not seem to define any variables by default, simply removing the code noticeably reduces start up time. > Windows 7, 64 bit, SSD -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:33 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-227: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > RejectedExecutionException when closing ModelControllerClient client > -------------------------------------------------------------------- > > Key: WFCORE-227 > URL: https://issues.jboss.org/browse/WFCORE-227 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 1.0.0.Alpha11 > Reporter: Alessio Soldano > Fix For: 1.0.0.Alpha13 > > > After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite: > {noformat} > Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3 at 5651c0c2 rejected from org.xnio.XnioWorker$TaskPool at 11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) > at org.xnio.XnioWorker.execute(XnioWorker.java:741) > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363) > at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method. > The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:33 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-223) Make the version specific methods in CommonXml private In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-223: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Make the version specific methods in CommonXml private > ------------------------------------------------------ > > Key: WFCORE-223 > URL: https://issues.jboss.org/browse/WFCORE-223 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > > Sub classes should call the non-version specific methods. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:34 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-217) CLI upload for op params with ModelType.BYTES In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-217: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > CLI upload for op params with ModelType.BYTES > --------------------------------------------- > > Key: WFCORE-217 > URL: https://issues.jboss.org/browse/WFCORE-217 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Affects Versions: 1.0.0.Alpha11 > Reporter: Stan Silvert > Assignee: Stan Silvert > Fix For: 1.0.0.Alpha13 > > > This Jira adds the same feature to regular CLI that was added to CLI GUI in WFCORE-204. > That is, for any operation who has a parameter type of ModelType.BYTES, treat the user-supplied value as a file path from which to retrieve those bytes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:34 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-213: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha13, 1.0.0.Beta1 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:35 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-137) Add Kerberos tests to domain-management module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-137: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Add Kerberos tests to domain-management module > ---------------------------------------------- > > Key: WFCORE-137 > URL: https://issues.jboss.org/browse/WFCORE-137 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:35 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-133) CLI -connect option throws full stacktrace exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-133: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > CLI -connect option throws full stacktrace exception > ---------------------------------------------------- > > Key: WFCORE-133 > URL: https://issues.jboss.org/browse/WFCORE-133 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha8 > Reporter: Joe Wertz > Assignee: Joe Wertz > Priority: Minor > Fix For: 1.0.0.Alpha13 > > > Full stacktrace is printed for exceptions that occur before the CLI connects to a server. > Instead, only the exception messages should be printed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:35 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-129) Overlay does not work for subunits in exploded deployments. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-129: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Overlay does not work for subunits in exploded deployments. > ----------------------------------------------------------- > > Key: WFCORE-129 > URL: https://issues.jboss.org/browse/WFCORE-129 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha8 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Alpha13 > > > If deployment is exploded and has subdeployments overlay wont work on files contained in said subdeployments. > Reproducers: https://github.com/baranowb/wildfly/tree/WFCORE-83-TESTS -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:36 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-107: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Update whoami operation to return authentication mechanism where verbose=true > ----------------------------------------------------------------------------- > > Key: WFCORE-107 > URL: https://issues.jboss.org/browse/WFCORE-107 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > > The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached. > This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:36 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-106) Enable GSSAPI/Kerberos Support for domain management over Remoting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-106: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Enable GSSAPI/Kerberos Support for domain management over Remoting > ------------------------------------------------------------------ > > Key: WFCORE-106 > URL: https://issues.jboss.org/browse/WFCORE-106 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:36 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-104) Add GSSAPI support to CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-104: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Add GSSAPI support to CLI > ------------------------- > > Key: WFCORE-104 > URL: https://issues.jboss.org/browse/WFCORE-104 > Project: WildFly Core > Issue Type: Sub-task > Components: CLI, Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: Kerberos, management_security, > Fix For: 1.0.0.Alpha13 > > > Once the Native interface supports GSSAPI then the CLI will also need to support this. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:37 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-103) Add Full Kerberos Support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-103: ------------------------------------ Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Add Full Kerberos Support > ------------------------- > > Key: WFCORE-103 > URL: https://issues.jboss.org/browse/WFCORE-103 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: management_security, > Fix For: 1.0.0.Alpha13 > > > There are a number of steps required to full add Kerberos support - this is a top level tracking task to be resolved once all steps are complete. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:38 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-94) Add -secmgr to startup scripts and propagate -secmgr through the domain In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-94: ----------------------------------- Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Add -secmgr to startup scripts and propagate -secmgr through the domain > ----------------------------------------------------------------------- > > Key: WFCORE-94 > URL: https://issues.jboss.org/browse/WFCORE-94 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Scripts > Reporter: Kabir Khan > Assignee: James Perkins > Fix For: 1.0.0.Alpha13 > > > The preferred mechanism to enable a security manager is to use the -secmgr module option. Modify the scripts to make this easier to add, and make adjustments to propagate this through the domain. > The -secmgr module option is not visible from the launched process, so for the process controller and host controller to pass that on to the started host controller or server process respectively, a check is added to see if a security manager was enabeld. If a security manager is enabled, and -Djava.security.manager is not present in the system properties, we add the -secmgr module option when starting the next process. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:38 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-80) Upgrade org.apache.httpcomponents:httpclient to 4.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-80: ----------------------------------- Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Upgrade org.apache.httpcomponents:httpclient to 4.3.2 > ----------------------------------------------------- > > Key: WFCORE-80 > URL: https://issues.jboss.org/browse/WFCORE-80 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Affects Versions: 1.0.0.Alpha5 > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-77) We need even better reporting for failed authentications In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-77: ----------------------------------- Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > We need even better reporting for failed authentications > -------------------------------------------------------- > > Key: WFCORE-77 > URL: https://issues.jboss.org/browse/WFCORE-77 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > > The following message is often the one reported to users: - > {noformat} > >> Caused by: javax.security.sasl.SaslException: Authentication failed: > >> the server presented no authentication mechanisms > {noformat} > Whilst technically it is true at that point in time this is most likely caused because other mechanisms have already been tried and failed and the list of mechanisms to try is now exhausted. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-54) Add Keycloak authentication/authorization to http management endpoint In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-54: ----------------------------------- Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Add Keycloak authentication/authorization to http management endpoint > --------------------------------------------------------------------- > > Key: WFCORE-54 > URL: https://issues.jboss.org/browse/WFCORE-54 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Stan Silvert > Assignee: Stan Silvert > Fix For: 1.0.0.Alpha13 > > > This is here to track the core changes needed for WFLY-3591. See that jira for details. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-31) The JBoss Modules schemas are missing from the build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-31: ----------------------------------- Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > The JBoss Modules schemas are missing from the build > ---------------------------------------------------- > > Key: WFCORE-31 > URL: https://issues.jboss.org/browse/WFCORE-31 > Project: WildFly Core > Issue Type: Bug > Reporter: Darran Lofthouse > Assignee: Eduardo Martins > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 18:36:41 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 18:36:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-25) Windows PowerShell scripts in bin In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-25: ----------------------------------- Fix Version/s: 1.0.0.Alpha13 (was: 1.0.0.Alpha12) > Windows PowerShell scripts in bin > --------------------------------- > > Key: WFCORE-25 > URL: https://issues.jboss.org/browse/WFCORE-25 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha13 > > > Add .psh scripts that match the functionality of our .sh scripts. Leave the .bat scripts in their current limited-functionality form for people still on XP, but use PowerShell as the recommended Windows scripting language. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 19:55:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 19:55:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-236) Refactor FileSystemDeploymentService.scan In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-236: --------------------------------------- Summary: Refactor FileSystemDeploymentService.scan Key: WFCORE-236 URL: https://issues.jboss.org/browse/WFCORE-236 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry FileSystemDeploymentService.scan needs to be refactored. It's currently handling 3 separate cases: one-off-scan during boot, normal scan, and post-boot "forced-undeploy" scan. Internally it has a lot of "if" logic to discriminate behavior between the three. Most of the shared logic between the three is one chunk of code that deals with executing the tasks that are identified. So look into factoring that part out and then creating a separate method for the "forced-undeploy" stuff. Also check if some of the stuff in the "finally" block can move to a finally block in the oneOffScan method. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 19:57:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 19:57:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-237) Use boot-completed notification to trigger deployment scanner "forced undeploy" scan In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-237: --------------------------------------- Summary: Use boot-completed notification to trigger deployment scanner "forced undeploy" scan Key: WFCORE-237 URL: https://issues.jboss.org/browse/WFCORE-237 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry The FileSystemDeploymentService "forced-undeploy" scan is scheduled based on an arbitrary 200 ms delay. Instead inject ControlledProcessStateService, install a listener, and have the listener schedule an immediate scan when it's notified that ControlledProcessState.RUNNING has been reached. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 9 20:55:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 9 Nov 2014 20:55:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-236) Refactor FileSystemDeploymentService.scan In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-236: --------------------------------------- Assignee: Brian Stansberry > Refactor FileSystemDeploymentService.scan > ----------------------------------------- > > Key: WFCORE-236 > URL: https://issues.jboss.org/browse/WFCORE-236 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > FileSystemDeploymentService.scan needs to be refactored. > It's currently handling 3 separate cases: one-off-scan during boot, normal scan, and post-boot "forced-undeploy" scan. Internally it has a lot of "if" logic to discriminate behavior between the three. > Most of the shared logic between the three is one chunk of code that deals with executing the tasks that are identified. So look into factoring that part out and then creating a separate method for the "forced-undeploy" stuff. Also check if some of the stuff in the "finally" block can move to a finally block in the oneOffScan method. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 00:46:30 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Mon, 10 Nov 2014 00:46:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4064) Web-fragments of Servlet 3 API doesn't work in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas resolved WFLY-4064. ---------------------------------- Resolution: Rejected You are using web.xml of version 2.3: {code} {code} You need to use version 2.5 or later for this to work, as web fragments where not part of the earlier version of the spec. {code} {code} > Web-fragments of Servlet 3 API doesn't work in WildFly > ------------------------------------------------------ > > Key: WFLY-4064 > URL: https://issues.jboss.org/browse/WFLY-4064 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web), Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Georgy Go > Assignee: Stuart Douglas > Attachments: test.zip > > > The same project with web-fragments works fine in Tomcat 8 and doesn't in WildFly 8.1.0.Final. > The problem is registred servlet unaccessable from it's path, failes with "Not Found" error. > Because it's works fine in Tomcat, I think it's bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 05:11:31 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 10 Nov 2014 05:11:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4065) Warning about private module use issued twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-4065: ------------------------------ Component/s: Class Loading (was: Server) > Warning about private module use issued twice > --------------------------------------------- > > Key: WFLY-4065 > URL: https://issues.jboss.org/browse/WFLY-4065 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 9.0.0.Beta1 > Reporter: Frank Langelage > Assignee: Jason Greene > Priority: Minor > > My web app is using some modules of WildFly AS which are not public. > The warning about using private modules is issued twice for every module: > 09.11. 22:07:34,088 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,090 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,092 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,094 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 05:12:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 10 Nov 2014 05:12:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4065) Warning about private module use issued twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-4065: --------------------------------- Assignee: David Lloyd (was: Jason Greene) > Warning about private module use issued twice > --------------------------------------------- > > Key: WFLY-4065 > URL: https://issues.jboss.org/browse/WFLY-4065 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 9.0.0.Beta1 > Reporter: Frank Langelage > Assignee: David Lloyd > Priority: Minor > > My web app is using some modules of WildFly AS which are not public. > The warning about using private modules is issued twice for every module: > 09.11. 22:07:34,088 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,090 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.jboss.common-core:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,091 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.commons.collections:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,092 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. > 09.11. 22:07:34,094 WARN [org.jboss.as.dependency.private#start] WFLYSRV0018: Deployment "deployment.web-maj2e-langfr-dev.war" is using a private module ("org.apache.cxf.impl:main") which may be changed or removed in future versions without notice. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 05:15:33 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Mon, 10 Nov 2014 05:15:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1901) GMS: view installation via two-phase commit In-Reply-To: References: Message-ID: Bela Ban created JGRP-1901: ------------------------------ Summary: GMS: view installation via two-phase commit Key: JGRP-1901 URL: https://issues.jboss.org/browse/JGRP-1901 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.1 Investigate whether view installation should optionally be done via 2PC. Example: * View is A,B,C,D, splits into A,B and C,D * Before AB is installed in A and B, view A,B,C is installed ** (C hasn't been suspected yet. This can happen with {{FD}}) Infinispan's rebalancing algorithm has problems with this, as it tries to assign state to C which however isn't reachable from the A,B side of the network partition. It would be better if A,B,C,D went directly to A,B and C,D Investigate whether we should add a property to {{GMS}} which defines whether to use 2PC for view installation (default would be {{false}}). The algorithm would work as follows: * Send a {{PREPARE_VIEW(view)}} message * When all responses have been received -> send a {{COMMIT_VIEW}} message * Else ** Inject SUSPECT(C) event for all misisng acks OR ** Set a timer to go off in N ms -> when it fires, send the {{COMMIT_VIEW}} msg ** If another view is installed before the tmer goes off (e.g. A,B) -> kill the timer -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 05:15:33 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Mon, 10 Nov 2014 05:15:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1901) GMS: view installation by consensus In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-1901: --------------------------- Summary: GMS: view installation by consensus (was: GMS: view installation via two-phase commit) > GMS: view installation by consensus > ----------------------------------- > > Key: JGRP-1901 > URL: https://issues.jboss.org/browse/JGRP-1901 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > Investigate whether view installation should optionally be done via 2PC. Example: > * View is A,B,C,D, splits into A,B and C,D > * Before AB is installed in A and B, view A,B,C is installed > ** (C hasn't been suspected yet. This can happen with {{FD}}) > Infinispan's rebalancing algorithm has problems with this, as it tries to assign state to C which however isn't reachable from the A,B side of the network partition. It would be better if A,B,C,D went directly to A,B and C,D > Investigate whether we should add a property to {{GMS}} which defines whether to use 2PC for view installation (default would be {{false}}). The algorithm would work as follows: > * Send a {{PREPARE_VIEW(view)}} message > * When all responses have been received -> send a {{COMMIT_VIEW}} message > * Else > ** Inject SUSPECT(C) event for all misisng acks OR > ** Set a timer to go off in N ms -> when it fires, send the {{COMMIT_VIEW}} msg > ** If another view is installed before the tmer goes off (e.g. A,B) -> kill the timer -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 05:21:29 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Mon, 10 Nov 2014 05:21:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1901) GMS: view installation by consensus In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018560#comment-13018560 ] Bela Ban commented on JGRP-1901: -------------------------------- Perhaps simpler: {noformat} - Start a task T to install view V: - Send a PREPARE_VIEW(V) to the target members - When acks from all target members have been received - send a COMMIT_VIEW(V) message to the targets - Else -> sleep and continue - When a new view is to be installed -> cancel T and start a new task - On reception of a PEPARE_VIEW(V) -> remove all previous pending views - On reception of a COMMIT_VIEW(V) -> install V and remove all previous pending views (< V) {noformat} > GMS: view installation by consensus > ----------------------------------- > > Key: JGRP-1901 > URL: https://issues.jboss.org/browse/JGRP-1901 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > Investigate whether view installation should optionally be done via 2PC. Example: > * View is A,B,C,D, splits into A,B and C,D > * Before AB is installed in A and B, view A,B,C is installed > ** (C hasn't been suspected yet. This can happen with {{FD}}) > Infinispan's rebalancing algorithm has problems with this, as it tries to assign state to C which however isn't reachable from the A,B side of the network partition. It would be better if A,B,C,D went directly to A,B and C,D > Investigate whether we should add a property to {{GMS}} which defines whether to use 2PC for view installation (default would be {{false}}). The algorithm would work as follows: > * Send a {{PREPARE_VIEW(view)}} message > * When all responses have been received -> send a {{COMMIT_VIEW}} message > * Else > ** Inject SUSPECT(C) event for all misisng acks OR > ** Set a timer to go off in N ms -> when it fires, send the {{COMMIT_VIEW}} msg > ** If another view is installed before the tmer goes off (e.g. A,B) -> kill the timer -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 05:53:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 10 Nov 2014 05:53:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4012) Updating the JBoss console login screen In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFLY-4012. ------------------------------------ Resolution: Rejected This will be possible as a side effect of other initiatives, it does not require it's own Jira issue. > Updating the JBoss console login screen > --------------------------------------- > > Key: WFLY-4012 > URL: https://issues.jboss.org/browse/WFLY-4012 > Project: WildFly > Issue Type: Enhancement > Components: Domain Management, Security, Web Console > Reporter: Carlton Zachary > Assignee: Darran Lofthouse > > Are there any plans in the works for updating the JBoss console (WFLY & EAP) login screen anytime soon? > It would be great to see something similar to this on the patternfly.org site https://www.patternfly.org/wp-content/uploads/2014/01/Patternfly-login.png. > WFLY and EAP are great enterprise platforms for Java EE applications and the login screen should reflect that. Oracle WebLogic and IBM Websphere already have such login screens for their consoles. > > Thanks -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 05:58:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 10 Nov 2014 05:58:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3894) Can't login JAAS secured management interfaces with --admin-only In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFLY-3894. ------------------------------------ Resolution: Rejected This is an area under active development anyway but generally the issue here is a decision has been made to run the server without starting the application server services and yet the management interface has been configured to delegate to an application server service. If delegation to JAAS is happening then admin only mode is not applicable for authentication. Otherwise the next logical step is now we may have a login module that requires JNDI and a database connection, next do we need to start to require transactions so before long a path to requiring all application server services becomes possible. > Can't login JAAS secured management interfaces with --admin-only > ---------------------------------------------------------------- > > Key: WFLY-3894 > URL: https://issues.jboss.org/browse/WFLY-3894 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 9.0.0.Alpha1 > Reporter: Chris Dolphy > Assignee: Darran Lofthouse > Attachments: standalone.xml > > > After configuring JAAS security for management realm, when I start JBoss with `bin/standalone.sh --admin-only', I can't login to the management web console. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 05:59:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 10 Nov 2014 05:59:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1652) The security realm PlugIns are currently returning roles, this should be group membership information. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFLY-1652. ------------------------------------ Fix Version/s: 9.0.0.Beta1 Resolution: Out of Date With the move to Elytron this whole area is under review anyway. > The security realm PlugIns are currently returning roles, this should be group membership information. > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-1652 > URL: https://issues.jboss.org/browse/WFLY-1652 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Labels: management_security, > Fix For: 9.0.0.Beta1 > > > Without breaking backwards compatibility this should be returning group membership information and not roles. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 06:05:29 2014 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Mon, 10 Nov 2014 06:05:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4066) add-user.bat is broken In-Reply-To: References: Message-ID: Juergen Zimmermann created WFLY-4066: ---------------------------------------- Summary: add-user.bat is broken Key: WFLY-4066 URL: https://issues.jboss.org/browse/WFLY-4066 Project: WildFly Issue Type: Bug Components: ConfigAdmin Affects Versions: 9.0.0.Beta1 Reporter: Juergen Zimmermann Assignee: Thomas Diesler When I invoke "add-user.bat ", then I'm getting this Windows error message (in German): {code} "that" kann syntaktisch an dieser Stelle nicht verarbeitet werden. {code} The solution is to remove the brackets in line 34, i.e. before: {code} echo WARNING: The JBOSS_HOME ("%SANITIZED_JBOSS_HOME%") that this script uses points to a different installation than the one that this script resides in ("%RESOLVED_JBOSS_HOME%"). Unpredictable results may occur. {code} After: {code} echo WARNING: The JBOSS_HOME "%SANITIZED_JBOSS_HOME%" that this script uses points to a different installation than the one that this script resides in "%RESOLVED_JBOSS_HOME%". Unpredictable results may occur. {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 06:07:29 2014 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Mon, 10 Nov 2014 06:07:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4066) add-user.bat is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juergen Zimmermann updated WFLY-4066: ------------------------------------- Forum Reference: https://developer.jboss.org/message/909659 > add-user.bat is broken > ---------------------- > > Key: WFLY-4066 > URL: https://issues.jboss.org/browse/WFLY-4066 > Project: WildFly > Issue Type: Bug > Components: ConfigAdmin > Affects Versions: 9.0.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Thomas Diesler > > When I invoke "add-user.bat ", then I'm getting this Windows error message (in German): > {code} > "that" kann syntaktisch an dieser Stelle nicht verarbeitet werden. > {code} > The solution is to remove the brackets in line 34, i.e. before: > {code} > echo WARNING: The JBOSS_HOME ("%SANITIZED_JBOSS_HOME%") that this script uses points to a different installation than the one that this script resides in ("%RESOLVED_JBOSS_HOME%"). Unpredictable results may occur. > {code} > After: > {code} > echo WARNING: The JBOSS_HOME "%SANITIZED_JBOSS_HOME%" that this script uses points to a different installation than the one that this script resides in "%RESOLVED_JBOSS_HOME%". Unpredictable results may occur. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 06:18:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 10 Nov 2014 06:18:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4066) add-user.bat is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reassigned WFLY-4066: -------------------------------------- Assignee: Darran Lofthouse (was: Thomas Diesler) > add-user.bat is broken > ---------------------- > > Key: WFLY-4066 > URL: https://issues.jboss.org/browse/WFLY-4066 > Project: WildFly > Issue Type: Bug > Components: ConfigAdmin > Affects Versions: 9.0.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Darran Lofthouse > > When I invoke "add-user.bat ", then I'm getting this Windows error message (in German): > {code} > "that" kann syntaktisch an dieser Stelle nicht verarbeitet werden. > {code} > The solution is to remove the brackets in line 34, i.e. before: > {code} > echo WARNING: The JBOSS_HOME ("%SANITIZED_JBOSS_HOME%") that this script uses points to a different installation than the one that this script resides in ("%RESOLVED_JBOSS_HOME%"). Unpredictable results may occur. > {code} > After: > {code} > echo WARNING: The JBOSS_HOME "%SANITIZED_JBOSS_HOME%" that this script uses points to a different installation than the one that this script resides in "%RESOLVED_JBOSS_HOME%". Unpredictable results may occur. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 06:19:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 10 Nov 2014 06:19:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4066) add-user.bat is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-4066: ----------------------------------- Component/s: Domain Management Scripts (was: ConfigAdmin) > add-user.bat is broken > ---------------------- > > Key: WFLY-4066 > URL: https://issues.jboss.org/browse/WFLY-4066 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Scripts > Affects Versions: 9.0.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Darran Lofthouse > > When I invoke "add-user.bat ", then I'm getting this Windows error message (in German): > {code} > "that" kann syntaktisch an dieser Stelle nicht verarbeitet werden. > {code} > The solution is to remove the brackets in line 34, i.e. before: > {code} > echo WARNING: The JBOSS_HOME ("%SANITIZED_JBOSS_HOME%") that this script uses points to a different installation than the one that this script resides in ("%RESOLVED_JBOSS_HOME%"). Unpredictable results may occur. > {code} > After: > {code} > echo WARNING: The JBOSS_HOME "%SANITIZED_JBOSS_HOME%" that this script uses points to a different installation than the one that this script resides in "%RESOLVED_JBOSS_HOME%". Unpredictable results may occur. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 06:19:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 10 Nov 2014 06:19:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4066) add-user.bat is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-4066: ----------------------------------- Fix Version/s: 9.0.0.Beta1 > add-user.bat is broken > ---------------------- > > Key: WFLY-4066 > URL: https://issues.jboss.org/browse/WFLY-4066 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Scripts > Affects Versions: 9.0.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > When I invoke "add-user.bat ", then I'm getting this Windows error message (in German): > {code} > "that" kann syntaktisch an dieser Stelle nicht verarbeitet werden. > {code} > The solution is to remove the brackets in line 34, i.e. before: > {code} > echo WARNING: The JBOSS_HOME ("%SANITIZED_JBOSS_HOME%") that this script uses points to a different installation than the one that this script resides in ("%RESOLVED_JBOSS_HOME%"). Unpredictable results may occur. > {code} > After: > {code} > echo WARNING: The JBOSS_HOME "%SANITIZED_JBOSS_HOME%" that this script uses points to a different installation than the one that this script resides in "%RESOLVED_JBOSS_HOME%". Unpredictable results may occur. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 06:32:29 2014 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Mon, 10 Nov 2014 06:32:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4057) jboss-cli.bat stops working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018582#comment-13018582 ] Juergen Zimmermann commented on WFLY-4057: ------------------------------------------ [~aloubyansky] do you need any additional information? > jboss-cli.bat stops working > --------------------------- > > Key: WFLY-4057 > URL: https://issues.jboss.org/browse/WFLY-4057 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 9.0.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Alexey Loubyansky > > I compiled the latest snapshot for 9.0.0.Alpha2. However, jboss-cli.bat doesn't work anymore. When I compiled the snapshot last week (Wed. 10/30/14 ?) jboss-cli.bat was working fine. Here is an example for the broken jboss-cli.bat: > {code} > jboss-cli.bat -c --command=:shutdown > ':shutdown' is assumed to be a command(s) but the commands to execute have been specified by another argument: [--command] > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 06:37:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Mon, 10 Nov 2014 06:37:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4064) Web-fragments of Servlet 3 API doesn't work in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018583#comment-13018583 ] Tomaz Cerar commented on WFLY-4064: ----------------------------------- More accurately, web-fragments ware introduced in version 3. > Web-fragments of Servlet 3 API doesn't work in WildFly > ------------------------------------------------------ > > Key: WFLY-4064 > URL: https://issues.jboss.org/browse/WFLY-4064 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web), Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Georgy Go > Assignee: Stuart Douglas > Attachments: test.zip > > > The same project with web-fragments works fine in Tomcat 8 and doesn't in WildFly 8.1.0.Final. > The problem is registred servlet unaccessable from it's path, failes with "Not Found" error. > Because it's works fine in Tomcat, I think it's bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 07:13:29 2014 From: issues at jboss.org (Stan Silvert (JIRA)) Date: Mon, 10 Nov 2014 07:13:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-217) CLI upload for op params with ModelType.BYTES In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stan Silvert resolved WFCORE-217. --------------------------------- Fix Version/s: 1.0.0.Alpha12 (was: 1.0.0.Alpha13) Resolution: Done > CLI upload for op params with ModelType.BYTES > --------------------------------------------- > > Key: WFCORE-217 > URL: https://issues.jboss.org/browse/WFCORE-217 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Affects Versions: 1.0.0.Alpha11 > Reporter: Stan Silvert > Assignee: Stan Silvert > Fix For: 1.0.0.Alpha12 > > > This Jira adds the same feature to regular CLI that was added to CLI GUI in WFCORE-204. > That is, for any operation who has a parameter type of ModelType.BYTES, treat the user-supplied value as a file path from which to retrieve those bytes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 07:55:29 2014 From: issues at jboss.org (Radim Vansa (JIRA)) Date: Mon, 10 Nov 2014 07:55:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1901) GMS: view installation by consensus In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018604#comment-13018604 ] Radim Vansa commented on JGRP-1901: ----------------------------------- Do you plan to ack the PREPARE_VIEW without leaving the old view? > GMS: view installation by consensus > ----------------------------------- > > Key: JGRP-1901 > URL: https://issues.jboss.org/browse/JGRP-1901 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > Investigate whether view installation should optionally be done via 2PC. Example: > * View is A,B,C,D, splits into A,B and C,D > * Before AB is installed in A and B, view A,B,C is installed > ** (C hasn't been suspected yet. This can happen with {{FD}}) > Infinispan's rebalancing algorithm has problems with this, as it tries to assign state to C which however isn't reachable from the A,B side of the network partition. It would be better if A,B,C,D went directly to A,B and C,D > Investigate whether we should add a property to {{GMS}} which defines whether to use 2PC for view installation (default would be {{false}}). The algorithm would work as follows: > * Send a {{PREPARE_VIEW(view)}} message > * When all responses have been received -> send a {{COMMIT_VIEW}} message > * Else > ** Inject SUSPECT(C) event for all misisng acks OR > ** Set a timer to go off in N ms -> when it fires, send the {{COMMIT_VIEW}} msg > ** If another view is installed before the tmer goes off (e.g. A,B) -> kill the timer -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 07:57:29 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Mon, 10 Nov 2014 07:57:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4057) jboss-cli.bat stops working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018605#comment-13018605 ] Alexey Loubyansky commented on WFLY-4057: ----------------------------------------- Not yet. I suspect it was a regression which should be fixed now with https://github.com/wildfly/wildfly-core/pull/292 being merged. Is there a chance you can try the current core? I don't have a windows machine here. If you can't, I'll find one this week. Thanks. > jboss-cli.bat stops working > --------------------------- > > Key: WFLY-4057 > URL: https://issues.jboss.org/browse/WFLY-4057 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 9.0.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Alexey Loubyansky > > I compiled the latest snapshot for 9.0.0.Alpha2. However, jboss-cli.bat doesn't work anymore. When I compiled the snapshot last week (Wed. 10/30/14 ?) jboss-cli.bat was working fine. Here is an example for the broken jboss-cli.bat: > {code} > jboss-cli.bat -c --command=:shutdown > ':shutdown' is assumed to be a command(s) but the commands to execute have been specified by another argument: [--command] > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 08:06:29 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Mon, 10 Nov 2014 08:06:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1901) GMS: view installation by consensus In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018610#comment-13018610 ] Bela Ban commented on JGRP-1901: -------------------------------- Yes. A node only installs committed views. > GMS: view installation by consensus > ----------------------------------- > > Key: JGRP-1901 > URL: https://issues.jboss.org/browse/JGRP-1901 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > Investigate whether view installation should optionally be done via 2PC. Example: > * View is A,B,C,D, splits into A,B and C,D > * Before AB is installed in A and B, view A,B,C is installed > ** (C hasn't been suspected yet. This can happen with {{FD}}) > Infinispan's rebalancing algorithm has problems with this, as it tries to assign state to C which however isn't reachable from the A,B side of the network partition. It would be better if A,B,C,D went directly to A,B and C,D > Investigate whether we should add a property to {{GMS}} which defines whether to use 2PC for view installation (default would be {{false}}). The algorithm would work as follows: > * Send a {{PREPARE_VIEW(view)}} message > * When all responses have been received -> send a {{COMMIT_VIEW}} message > * Else > ** Inject SUSPECT(C) event for all misisng acks OR > ** Set a timer to go off in N ms -> when it fires, send the {{COMMIT_VIEW}} msg > ** If another view is installed before the tmer goes off (e.g. A,B) -> kill the timer -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 08:10:29 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Mon, 10 Nov 2014 08:10:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3999) cli deployment-overlay --redeploy-affected should check subdeployments as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Loubyansky resolved WFLY-3999. ------------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done This has been released with the core 1.0.0.Alpha11 which is now used by the WildFly build. > cli deployment-overlay --redeploy-affected should check subdeployments as well > ------------------------------------------------------------------------------ > > Key: WFLY-3999 > URL: https://issues.jboss.org/browse/WFLY-3999 > Project: WildFly > Issue Type: Enhancement > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 9.0.0.Beta1 > > > This issue has to be fixed in wildfly-core but the overlay tests are in the WildFly testsuite. This issue is for the tests covering this issue in WildFly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 08:25:38 2014 From: issues at jboss.org (Radim Vansa (JIRA)) Date: Mon, 10 Nov 2014 08:25:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1901) GMS: view installation by consensus In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018621#comment-13018621 ] Radim Vansa commented on JGRP-1901: ----------------------------------- In that case, it won't completely be a consensus - the node should not ack the PREPARE_VIEW before it can be sure that it was removed from the old one (either gracefully through some kind of leave, or by timeout-based means such as FDx protocols). If one node is reachable from both partition to another one, the old partition would still think that the node is part of that view (until it gets suspected, and that can take a while), and allow modifications in the old partition, and consequently allow modifications in the new one. I know I am talking about a use case tailored for Infinispan specifically, but after all, this is why we are dealing with this JIRA. > GMS: view installation by consensus > ----------------------------------- > > Key: JGRP-1901 > URL: https://issues.jboss.org/browse/JGRP-1901 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > Investigate whether view installation should optionally be done via 2PC. Example: > * View is A,B,C,D, splits into A,B and C,D > * Before AB is installed in A and B, view A,B,C is installed > ** (C hasn't been suspected yet. This can happen with {{FD}}) > Infinispan's rebalancing algorithm has problems with this, as it tries to assign state to C which however isn't reachable from the A,B side of the network partition. It would be better if A,B,C,D went directly to A,B and C,D > Investigate whether we should add a property to {{GMS}} which defines whether to use 2PC for view installation (default would be {{false}}). The algorithm would work as follows: > * Send a {{PREPARE_VIEW(view)}} message > * When all responses have been received -> send a {{COMMIT_VIEW}} message > * Else > ** Inject SUSPECT(C) event for all misisng acks OR > ** Set a timer to go off in N ms -> when it fires, send the {{COMMIT_VIEW}} msg > ** If another view is installed before the tmer goes off (e.g. A,B) -> kill the timer -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 10 09:23:32 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Mon, 10 Nov 2014 09:23:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1149) Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd resolved WFLY-1149. ------------------------------- Assignee: Jason Greene Resolution: Done > Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open. > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1149 > URL: https://issues.jboss.org/browse/WFLY-1149 > Project: WildFly > Issue Type: Bug > Components: Naming, Test Suite > Environment: IBM JDK 6 (build 20110203_074623) > IBM JDK 7 (build 20120809_118929) > Reporter: Ivo Studensky > Assignee: Jason Greene > Attachments: endpoint_is_not_open_2012-11-26.xml, failed_with_status_cancelled_2012-11-26.xml, test_output_with_trace_logging_in_EndpointCache.xml > > > RemoteNamingTestCase intermittently fails when running on IBM JDK. According to logs the remoting channel had been closed before the endpoint tried to connect to it. Unfortunately, when I was trying to debug this issue the tests always nicely passed. > test.log snippet: > {noformat} > 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" read-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" read-1', selector sun.nio.ch.EPollSelectorImpl at 345642e1 > 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" write-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" write-1', selector sun.nio.ch.EPollSelectorImpl at 1dc68cf2 > 13:16:31,121 DEBUG [org.jboss.naming.remote.client.InitialContextFactory] (main) jboss.naming.client.connect.options. has the following options {org.xnio.Options.SASL_POLICY_NOPLAINTEXT=>false} > 13:16:31,191 ERROR [org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1] (Remoting "config-based-naming-client-endpoint" task-1) Channel end notification received, closing channel Channel ID d1f17196 (outbound) of Remoting connection fd3dcedc to /127.0.0.1:4447 > 13:16:31,204 DEBUG [org.jboss.naming.remote.client.HaRemoteNamingStore] (main) Failed to connect to server remote://127.0.0.1:4447: org.jboss.remoting3.NotOpenException: Endpoint is not open > at org.jboss.remoting3.EndpointImpl.resourceUntick(EndpointImpl.java:182) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:261) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333) > at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105) > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:179) > at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:117) > at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83) > at javax.naming.InitialContext.lookup(InitialContext.java:422) > at org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase.testRemoteLookup(RemoteNamingTestCase.java:74) > {noformat} > server.log snippet: > {noformat} > 13:16:31,025 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "test.jar" > 13:16:31,163 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-3) Channel Opened - Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 > 13:16:31,176 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-4) Chosen version 0x01 > 13:16:31,189 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" read-1) Channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 closed. > 13:16:31,193 INFO [org.jboss.as.naming] (Remoting "thinkpax" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to null > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:25 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:33:25 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate In-Reply-To: References: Message-ID: Tom Schuller created WFLY-4067: ---------------------------------- Summary: DummyTransaction exception during session.invalidate Key: WFLY-4067 URL: https://issues.jboss.org/browse/WFLY-4067 Project: WildFly Issue Type: Bug Affects Versions: 9.0.0.Alpha1 Reporter: Tom Schuller Assignee: Jason Greene Attachments: convTest.war, convTest.zip A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:26 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 11 Nov 2014 09:33:26 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-4067: ------------------------------ Component/s: Clustering > DummyTransaction exception during session.invalidate > ---------------------------------------------------- > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Jason Greene > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:26 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 11 Nov 2014 09:33:26 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar reassigned WFLY-4067: --------------------------------- Assignee: Paul Ferraro (was: Jason Greene) > DummyTransaction exception during session.invalidate > ---------------------------------------------------- > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:28 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:33:28 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schuller updated WFLY-4067: ------------------------------- Attachment: convTest.zip sample to reproduce it > DummyTransaction exception during session.invalidate > ---------------------------------------------------- > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:29 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:33:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018648#comment-13018648 ] Tom Schuller edited comment on WFLY-4067 at 11/10/14 9:36 AM: -------------------------------------------------------------- added "convTest.zip" sample with sources to reproduce it was (Author: tomlux): sample to reproduce it > DummyTransaction exception during session.invalidate > ---------------------------------------------------- > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:33:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-154) Patching does not process subdirectories In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018649#comment-13018649 ] RH Bugzilla Integration commented on WFCORE-154: ------------------------------------------------ Jan Martiska changed the Status of [bug 1134735|https://bugzilla.redhat.com/show_bug.cgi?id=1134735] from ON_QA to VERIFIED > Patching does not process subdirectories > ---------------------------------------- > > Key: WFCORE-154 > URL: https://issues.jboss.org/browse/WFCORE-154 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 1.0.0.Alpha9 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Alpha10 > > > If patched resource is in subdirectory of moduleRoot, it is not included as part of patch, even though it is present in patch zip. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:30 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:33:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schuller updated WFLY-4067: ------------------------------- Steps to Reproduce: What we are to reproduce the problem:. - downloading WildFly-latest-master #1470 [Jenkins] - added an management user for the console with "add-user.bat" - changing in %JBOSS_HOME%\domain\configuration\domain.xml the "cluster-password" to a real password - starting up with "domain.bat" and loading the console (http://localhost:9990) - changed the "main-server-group" to "full-ha" profile with "full-ha-sockets" binding - restarted the WildFly support to get it running in "full-ha" - deplayed the convTest.war (see attachment convTest.zip) to the main-server-group and enabled it - doing the test: - opening http://localhost:8080/convTest/step1.jsf - starting a conversation by clicking on "startConversation" button - clicking the "logout" button to invalidate the session => DummyTransactionException Workaround Description: (was: What we are to reproduce the problem:. - downloading WildFly-latest-master #1470 [Jenkins] - added an management user for the console with "add-user.bat" - changing in %JBOSS_HOME%\domain\configuration\domain.xml the "cluster-password" to a real password - starting up with "domain.bat" and loading the console (http://localhost:9990) - changed the "main-server-group" to "full-ha" profile with "full-ha-sockets" binding - restarted the WildFly support to get it running in "full-ha" - deplayed the convTest.war (see attachment convTest.zip) to the main-server-group and enabled it - doing the test: - opening http://localhost:8080/convTest/step1.jsf - starting a conversation by clicking on "startConversation" button - clicking the "logout" button to invalidate the session => DummyTransactionException) > DummyTransaction exception during session.invalidate > ---------------------------------------------------- > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:30 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:33:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schuller updated WFLY-4067: ------------------------------- Steps to Reproduce: What we are doing to reproduce the problem:. - downloading WildFly-latest-master #1470 [Jenkins] - added an management user for the console with "add-user.bat" - changing in %JBOSS_HOME%\domain\configuration\domain.xml the "cluster-password" to a real password - starting up with "domain.bat" and loading the console (http://localhost:9990) - changed the "main-server-group" to "full-ha" profile with "full-ha-sockets" binding - restarted the WildFly support to get it running in "full-ha" - deplayed the convTest.war (see attachment convTest.zip) to the main-server-group and enabled it - doing the test: - opening http://localhost:8080/convTest/step1.jsf - starting a conversation by clicking on "startConversation" button - clicking the "logout" button to invalidate the session => DummyTransactionException was: What we are to reproduce the problem:. - downloading WildFly-latest-master #1470 [Jenkins] - added an management user for the console with "add-user.bat" - changing in %JBOSS_HOME%\domain\configuration\domain.xml the "cluster-password" to a real password - starting up with "domain.bat" and loading the console (http://localhost:9990) - changed the "main-server-group" to "full-ha" profile with "full-ha-sockets" binding - restarted the WildFly support to get it running in "full-ha" - deplayed the convTest.war (see attachment convTest.zip) to the main-server-group and enabled it - doing the test: - opening http://localhost:8080/convTest/step1.jsf - starting a conversation by clicking on "startConversation" button - clicking the "logout" button to invalidate the session => DummyTransactionException > DummyTransaction exception during session.invalidate > ---------------------------------------------------- > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:31 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:33:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schuller updated WFLY-4067: ------------------------------- Steps to Reproduce: What we are doing to reproduce the problem:. - downloading WildFly-latest-master #1470 [Jenkins] - added an management user for the console with "add-user.bat" - changing in %JBOSS_HOME%\domain\configuration\domain.xml the "cluster-password" to a real password - starting up with "domain.bat" and loading the console (http://localhost:9990) - changed the "main-server-group" to "full-ha" profile with "full-ha-sockets" binding - restarted the WildFly support to get it running in "full-ha" - deplayed the convTest.war (see attachment convTest.zip) to the main-server-group and enabled it - doing the test: -- opening http://localhost:8080/convTest/step1.jsf -- starting a conversation by clicking on "startConversation" button -- clicking the "logout" button to invalidate the session => DummyTransactionException was: What we are doing to reproduce the problem:. - downloading WildFly-latest-master #1470 [Jenkins] - added an management user for the console with "add-user.bat" - changing in %JBOSS_HOME%\domain\configuration\domain.xml the "cluster-password" to a real password - starting up with "domain.bat" and loading the console (http://localhost:9990) - changed the "main-server-group" to "full-ha" profile with "full-ha-sockets" binding - restarted the WildFly support to get it running in "full-ha" - deplayed the convTest.war (see attachment convTest.zip) to the main-server-group and enabled it - doing the test: - opening http://localhost:8080/convTest/step1.jsf - starting a conversation by clicking on "startConversation" button - clicking the "logout" button to invalidate the session => DummyTransactionException > DummyTransaction exception during session.invalidate > ---------------------------------------------------- > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:31 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:33:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate with started conversation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schuller updated WFLY-4067: ------------------------------- Summary: DummyTransaction exception during session.invalidate with started conversation (was: DummyTransaction exception during session.invalidate) > DummyTransaction exception during session.invalidate with started conversation > ------------------------------------------------------------------------------ > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:33 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:33:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate with started conversation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schuller updated WFLY-4067: ------------------------------- Description: A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. We are working in "full-ha" with session distribution enable ( in web.xml) Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) was: A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) > DummyTransaction exception during session.invalidate with started conversation > ------------------------------------------------------------------------------ > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > We are working in "full-ha" with session distribution enable ( in web.xml) > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:33 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:33:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate with started conversation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schuller updated WFLY-4067: ------------------------------- Description: A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. We are working in "full-ha" with session distribution enabled ( in web.xml) Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) was: A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. We are working in "full-ha" with session distribution enable ( in web.xml) Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) > DummyTransaction exception during session.invalidate with started conversation > ------------------------------------------------------------------------------ > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > We are working in "full-ha" with session distribution enabled ( in web.xml) > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:34 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:33:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate with started conversation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schuller updated WFLY-4067: ------------------------------- Steps to Reproduce: What we are doing to reproduce the problem:. - downloading WildFly-latest-master #1470 [Jenkins] - added an management user for the console with "add-user.bat" - changing in %JBOSS_HOME%\domain\configuration\domain.xml the "cluster-password" to a real password - starting up with "domain.bat" and loading the console (http://localhost:9990) - changed the "main-server-group" to "full-ha" profile with "full-ha-sockets" binding - restarted the WildFly support to get it running in "full-ha" - deployed the convTest.war (see attachment convTest.zip) to the main-server-group and enabled it - doing the test: -- opening http://localhost:8080/convTest/step1.jsf -- starting a conversation by clicking on "startConversation" button -- clicking the "logout" button to invalidate the session => DummyTransactionException was: What we are doing to reproduce the problem:. - downloading WildFly-latest-master #1470 [Jenkins] - added an management user for the console with "add-user.bat" - changing in %JBOSS_HOME%\domain\configuration\domain.xml the "cluster-password" to a real password - starting up with "domain.bat" and loading the console (http://localhost:9990) - changed the "main-server-group" to "full-ha" profile with "full-ha-sockets" binding - restarted the WildFly support to get it running in "full-ha" - deplayed the convTest.war (see attachment convTest.zip) to the main-server-group and enabled it - doing the test: -- opening http://localhost:8080/convTest/step1.jsf -- starting a conversation by clicking on "startConversation" button -- clicking the "logout" button to invalidate the session => DummyTransactionException > DummyTransaction exception during session.invalidate with started conversation > ------------------------------------------------------------------------------ > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > We are working in "full-ha" with session distribution enabled ( in web.xml) > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:37 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:33:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2645) SFSB containing injected DataSource fails to passivate/serialize In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018658#comment-13018658 ] RH Bugzilla Integration commented on WFLY-2645: ----------------------------------------------- Stefano Maestri changed the Status of [bug 901300|https://bugzilla.redhat.com/show_bug.cgi?id=901300] from ASSIGNED to POST > SFSB containing injected DataSource fails to passivate/serialize > ---------------------------------------------------------------- > > Key: WFLY-2645 > URL: https://issues.jboss.org/browse/WFLY-2645 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Stefano Maestri > Priority: Critical > > See JBPAPP6-1762 for details. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:33:52 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Tue, 11 Nov 2014 09:33:52 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-202) Deadlock when shutdown Wildfly server during CLI client connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Loubyansky updated WFCORE-202: ------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/312 (was: https://github.com/wildfly/wildfly-core/pull/305) > Deadlock when shutdown Wildfly server during CLI client connection > ------------------------------------------------------------------ > > Key: WFCORE-202 > URL: https://issues.jboss.org/browse/WFCORE-202 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha10 > Reporter: Chao Wang > Assignee: Alexey Loubyansky > > Creating upstream issue as the same deadlock can be found in WFLY. > Descirption as comment 5 in [BZ1142538|https://bugzilla.redhat.com/show_bug.cgi?id=1142538] > {noformat} > The following deadlock still exists. > Steps to Reproduce: > 1. Prepare a running EAP instance with secured management port - optionally in VM > 2. Execute export JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" > 3. In the same terminal, execute "bin/jboss-cli.sh --connect --controller=$EAP_IP --user=admin --password=password ':read-resource'" > 4. From yet another terminal, execute "jdb -attach localhost:8787" > 5. In JDB: > 5.a. Create breakpoint: "stop in org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 5.b. Resume all threads: "resume" > 5.c. [Execute five times] Wait until breakpoint is hit and execute "resume". Either set timeout or be fast so that timeout does not occur first > 6. Execute "kill -9 $EAP_PID" - optionally in VM > 7. In JDB: > 8.a. Remove breakpoint: "clear org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 8.b. Resume all threads: "resume" > 9. Now dump the stack trace of jboss-cli.sh: "kill -3 $JBOSS_CLI_PID" > Found one Java-level deadlock: > ============================= > "Remoting "cli-client" read-1": > waiting to lock monitor 0x00007ff9c829b558 (object 0x0000000783433408, a java.lang.String), > which is held by "main" > "main": > waiting to lock monitor 0x00007ff9c8333c48 (object 0x00000007851ae6e0, a java.util.ArrayDeque), > which is held by "Remoting "cli-client" read-1" > Java stack information for the threads listed above: > =================================================== > "Remoting "cli-client" read-1": > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:286) > - waiting to lock <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:269) > at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54) > at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:532) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) > at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:392) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:109) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:81) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:183) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.nio.NioHandle.run(NioHandle.java:90) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:198) > "main": > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:361) > - waiting to lock <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.connectionOpened(FutureManagementChannel.java:217) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:78) > - locked <0x0000000784978a00> (a org.jboss.as.protocol.ProtocolConnectionManager) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160) > - locked <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:123) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:98) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:980) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:841) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:817) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:250) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > 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:483) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > {noformat} > It can be easily reproduce with Eclipse as: > {noformat} > 1 start Wildfly > 2 uncomment "JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" in jboss-cli.sh and connect to server > 3 add two break points at > CLIModelControllerClient$ChannelCloseHandler [line: 285] - handleClose(Channel, IOException) > RemoteConnectionChannel [line: 360] - receiveMessage(Receiver) > 4 connect to 8787 from eclipse debug > 5 shutdown Wildfly > A deadlock between "main" and "cli-client" is in Eclipse debug stack. > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:11 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:34:11 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate with started conversation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schuller updated WFLY-4067: ------------------------------- Attachment: convTest.war conrrect version > DummyTransaction exception during session.invalidate with started conversation > ------------------------------------------------------------------------------ > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > We are working in "full-ha" with session distribution enabled ( in web.xml) > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:11 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:34:11 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate with started conversation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schuller updated WFLY-4067: ------------------------------- Attachment: convTest.zip correct version (srouces) > DummyTransaction exception during session.invalidate with started conversation > ------------------------------------------------------------------------------ > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > We are working in "full-ha" with session distribution enabled ( in web.xml) > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:13 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:34:13 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate with started conversation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018726#comment-13018726 ] Tom Schuller edited comment on WFLY-4067 at 11/10/14 11:23 AM: --------------------------------------------------------------- correct convTest.zip version (sources),please remove version 11/10/2014 3:35 PM was (Author: tomlux): correct version (srouces) > DummyTransaction exception during session.invalidate with started conversation > ------------------------------------------------------------------------------ > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > We are working in "full-ha" with session distribution enabled ( in web.xml) > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:16 2014 From: issues at jboss.org (Tom Schuller (JIRA)) Date: Tue, 11 Nov 2014 09:34:16 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate with started conversation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Schuller updated WFLY-4067: ------------------------------- Description: A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. We are working in "full-ha" with session distribution enabled ( in web.xml) Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1475) was: A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. We are working in "full-ha" with session distribution enabled ( in web.xml) Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1471) > DummyTransaction exception during session.invalidate with started conversation > ------------------------------------------------------------------------------ > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > We are working in "full-ha" with session distribution enabled ( in web.xml) > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1475) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:28 2014 From: issues at jboss.org (Juergen Zimmermann (JIRA)) Date: Tue, 11 Nov 2014 09:34:28 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4057) jboss-cli.bat stops working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018734#comment-13018734 ] Juergen Zimmermann commented on WFLY-4057: ------------------------------------------ [~aloubyansky] I just compiled the latest snapshot: the issue is gone. Thank you! > jboss-cli.bat stops working > --------------------------- > > Key: WFLY-4057 > URL: https://issues.jboss.org/browse/WFLY-4057 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 9.0.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Alexey Loubyansky > > I compiled the latest snapshot for 9.0.0.Alpha2. However, jboss-cli.bat doesn't work anymore. When I compiled the snapshot last week (Wed. 10/30/14 ?) jboss-cli.bat was working fine. Here is an example for the broken jboss-cli.bat: > {code} > jboss-cli.bat -c --command=:shutdown > ':shutdown' is assumed to be a command(s) but the commands to execute have been specified by another argument: [--command] > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:28 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 11 Nov 2014 09:34:28 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-123) Wrapping KeyStore to support storing passwords in standard KeyStores In-Reply-To: References: Message-ID: David Lloyd created ELY-123: ------------------------------- Summary: Wrapping KeyStore to support storing passwords in standard KeyStores Key: ELY-123 URL: https://issues.jboss.org/browse/ELY-123 Project: WildFly Elytron Issue Type: Feature Request Components: KeyStores Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:31 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 11 Nov 2014 09:34:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4068) Clean up Remoting Subsystem attribute definitions. In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-4068: -------------------------------------- Summary: Clean up Remoting Subsystem attribute definitions. Key: WFLY-4068 URL: https://issues.jboss.org/browse/WFLY-4068 Project: WildFly Issue Type: Bug Components: Remoting Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 8.2.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:32 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 11 Nov 2014 09:34:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4069) Clean up Remoting Subsystem attribute definitions. In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-4069: -------------------------------------- Summary: Clean up Remoting Subsystem attribute definitions. Key: WFLY-4069 URL: https://issues.jboss.org/browse/WFLY-4069 Project: WildFly Issue Type: Bug Components: Remoting Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 8.2.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:33 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:34:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3998) Add option to define enabled cipher suites within SSL definitions in security realms. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018742#comment-13018742 ] RH Bugzilla Integration commented on WFLY-3998: ----------------------------------------------- Radim Hatlapatka changed the Status of [bug 1153854|https://bugzilla.redhat.com/show_bug.cgi?id=1153854] from ON_QA to VERIFIED > Add option to define enabled cipher suites within SSL definitions in security realms. > ------------------------------------------------------------------------------------- > > Key: WFLY-3998 > URL: https://issues.jboss.org/browse/WFLY-3998 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:32 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:34:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-182) provide means to specify allowed ciphers for management https or change default to exclude weak ciphers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018740#comment-13018740 ] RH Bugzilla Integration commented on WFCORE-182: ------------------------------------------------ Radim Hatlapatka changed the Status of [bug 1153854|https://bugzilla.redhat.com/show_bug.cgi?id=1153854] from ON_QA to VERIFIED > provide means to specify allowed ciphers for management https or change default to exclude weak ciphers > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-182 > URL: https://issues.jboss.org/browse/WFCORE-182 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: R Stokoe > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha11 > > > Provide means to specify allowed ciphers for management https. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:33 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:34:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3993) Add attribute to specify enabled-protocols for HTTPS within domain management. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018743#comment-13018743 ] RH Bugzilla Integration commented on WFLY-3993: ----------------------------------------------- Radim Hatlapatka changed the Status of [bug 1153854|https://bugzilla.redhat.com/show_bug.cgi?id=1153854] from ON_QA to VERIFIED > Add attribute to specify enabled-protocols for HTTPS within domain management. > ------------------------------------------------------------------------------ > > Key: WFLY-3993 > URL: https://issues.jboss.org/browse/WFLY-3993 > Project: WildFly > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:33 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:34:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-180) Add attribute to specify enabled-protocols for HTTPS within domain management. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018741#comment-13018741 ] RH Bugzilla Integration commented on WFCORE-180: ------------------------------------------------ Radim Hatlapatka changed the Status of [bug 1153854|https://bugzilla.redhat.com/show_bug.cgi?id=1153854] from ON_QA to VERIFIED > Add attribute to specify enabled-protocols for HTTPS within domain management. > ------------------------------------------------------------------------------ > > Key: WFCORE-180 > URL: https://issues.jboss.org/browse/WFCORE-180 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.0.0.Alpha11 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:34 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 11 Nov 2014 09:34:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-238) Clean up Remoting Subsystem attribute definitions. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-4069 to WFCORE-238: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-238 (was: WFLY-4069) Component/s: Remoting (was: Remoting) Fix Version/s: 1.0.0.Alpha13 (was: 8.2.0.CR1) > Clean up Remoting Subsystem attribute definitions. > -------------------------------------------------- > > Key: WFCORE-238 > URL: https://issues.jboss.org/browse/WFCORE-238 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:37 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 11 Nov 2014 09:34:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-102) Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry resolved WFCORE-102. ------------------------------------- Fix Version/s: 1.0.0.Alpha9 (was: 1.0.0.Beta1) Resolution: Done > Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback > -------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-102 > URL: https://issues.jboss.org/browse/WFCORE-102 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha9 > > > The various base classes OSH authors use to create handlers force the author to deal with ServiceVerificationHandler and, during rollback, with removing any services the OSH added. This task is to have the OperationContext handle these things transparently, removing the need for authors to do so. > To preserve compatibility, the various API methods authors may have overridden that expose the SVH and the list of added ServiceControllers will be retained (but deprecated), but the SVH and the list of handlers won't be used. The API javadoc will encourage use of method variants that don't use these parameters. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:54 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 11 Nov 2014 09:34:54 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4064) Web-fragments of Servlet 3 API doesn't work in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018764#comment-13018764 ] Stuart Douglas commented on WFLY-4064: -------------------------------------- Even more accurately they need a Servlet 2.5 or above descriptor (or no descriptor) in a Servlet 3.0 or above container. Descriptors below 2.5 are considered metadata-complete, which means that no scanning is performed and web fragments are ignored. Servlet 2.5 introduced the notion of metadata completeness, so if a deployment with a 2.5 descriptor is not marked as metadata complete web fragments must still be processed. > Web-fragments of Servlet 3 API doesn't work in WildFly > ------------------------------------------------------ > > Key: WFLY-4064 > URL: https://issues.jboss.org/browse/WFLY-4064 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web), Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Georgy Go > Assignee: Stuart Douglas > Attachments: test.zip > > > The same project with web-fragments works fine in Tomcat 8 and doesn't in WildFly 8.1.0.Final. > The problem is registred servlet unaccessable from it's path, failes with "Not Found" error. > Because it's works fine in Tomcat, I think it's bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:55 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Tue, 11 Nov 2014 09:34:55 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1233) Make pool lock across all credentials In-Reply-To: References: Message-ID: Jesper Pedersen created JBJCA-1233: -------------------------------------- Summary: Make pool lock across all credentials Key: JBJCA-1233 URL: https://issues.jboss.org/browse/JBJCA-1233 Project: IronJacamar Issue Type: Task Components: Core Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.2.1.Final Previous pool lock was per crendential leading to more tricky setup in cases where multiple credentials were used per pool -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:55 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Tue, 11 Nov 2014 09:34:55 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate with started conversation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro updated WFLY-4067: ------------------------------- Attachment: (was: convTest.zip) > DummyTransaction exception during session.invalidate with started conversation > ------------------------------------------------------------------------------ > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > We are working in "full-ha" with session distribution enabled ( in web.xml) > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1475) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:56 2014 From: issues at jboss.org (Patson Luk (JIRA)) Date: Tue, 11 Nov 2014 09:34:56 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4070) Dispatcher modifies result of getRequestURI of the original request object In-Reply-To: References: Message-ID: Patson Luk created WFLY-4070: -------------------------------- Summary: Dispatcher modifies result of getRequestURI of the original request object Key: WFLY-4070 URL: https://issues.jboss.org/browse/WFLY-4070 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 9.0.0.Alpha1, 8.1.0.Final Reporter: Patson Luk Assignee: Stuart Douglas Attachments: test-wildfly.war, test-wildfly.zip This is actually similar to https://issues.jboss.org/browse/WFLY-2388, which was fixed in 8.0.0.CR1 However, it seems like with RequestDispatcher forward, the ORIGINAL ServletRequest object's getRequestURI returns the forwarded URI as the result, which is not correct. It is expected that the original ServletRequest object should retain its originating requested URI throughout the processing. This seems to affect all the versions of Wildfly (tested on 8.1 and 9.0 alpha) Take note that this has also been tested on JBoss AS 7 and tomcat 7, both have correctly retained the originating URI as expected even after dispatcher forwards -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:56 2014 From: issues at jboss.org (Patson Luk (JIRA)) Date: Tue, 11 Nov 2014 09:34:56 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4070) Dispatcher modifies result of getRequestURI of the original request object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patson Luk updated WFLY-4070: ----------------------------- Attachment: test-wildfly.war Sample project in war format Please access the root The request URI value will be printed to the System.out and indicates that getRequestURI returns /index.jsp instead of just / > Dispatcher modifies result of getRequestURI of the original request object > -------------------------------------------------------------------------- > > Key: WFLY-4070 > URL: https://issues.jboss.org/browse/WFLY-4070 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Patson Luk > Assignee: Stuart Douglas > Attachments: test-wildfly.war, test-wildfly.zip > > > This is actually similar to https://issues.jboss.org/browse/WFLY-2388, which was fixed in 8.0.0.CR1 > However, it seems like with RequestDispatcher forward, the ORIGINAL ServletRequest object's getRequestURI returns the forwarded URI as the result, which is not correct. It is expected that the original ServletRequest object should retain its originating requested URI throughout the processing. > This seems to affect all the versions of Wildfly (tested on 8.1 and 9.0 alpha) > Take note that this has also been tested on JBoss AS 7 and tomcat 7, both have correctly retained the originating URI as expected even after dispatcher forwards -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:57 2014 From: issues at jboss.org (Patson Luk (JIRA)) Date: Tue, 11 Nov 2014 09:34:57 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4070) Dispatcher modifies result of getRequestURI of the original request object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patson Luk updated WFLY-4070: ----------------------------- Attachment: test-wildfly.zip Source code > Dispatcher modifies result of getRequestURI of the original request object > -------------------------------------------------------------------------- > > Key: WFLY-4070 > URL: https://issues.jboss.org/browse/WFLY-4070 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Patson Luk > Assignee: Stuart Douglas > Attachments: test-wildfly.war, test-wildfly.zip > > > This is actually similar to https://issues.jboss.org/browse/WFLY-2388, which was fixed in 8.0.0.CR1 > However, it seems like with RequestDispatcher forward, the ORIGINAL ServletRequest object's getRequestURI returns the forwarded URI as the result, which is not correct. It is expected that the original ServletRequest object should retain its originating requested URI throughout the processing. > This seems to affect all the versions of Wildfly (tested on 8.1 and 9.0 alpha) > Take note that this has also been tested on JBoss AS 7 and tomcat 7, both have correctly retained the originating URI as expected even after dispatcher forwards -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:34:58 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 11 Nov 2014 09:34:58 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-239) Socket binding remove does not respect allow-resource-service-restart In-Reply-To: References: Message-ID: Stuart Douglas created WFCORE-239: ------------------------------------- Summary: Socket binding remove does not respect allow-resource-service-restart Key: WFCORE-239 URL: https://issues.jboss.org/browse/WFCORE-239 Project: WildFly Core Issue Type: Bug Reporter: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:35:15 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 11 Nov 2014 09:35:15 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4070) Dispatcher modifies result of getRequestURI of the original request object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018796#comment-13018796 ] Stuart Douglas commented on WFLY-4070: -------------------------------------- I don't really know if the spec actually specifies this behaviour, and it would be fairly problematic if the forward method calls startAsync() (as we don't actually wrap the original request, just modify the internal state). Do you know if other containers behave the same way? > Dispatcher modifies result of getRequestURI of the original request object > -------------------------------------------------------------------------- > > Key: WFLY-4070 > URL: https://issues.jboss.org/browse/WFLY-4070 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Patson Luk > Assignee: Stuart Douglas > Attachments: test-wildfly.war, test-wildfly.zip > > > This is actually similar to https://issues.jboss.org/browse/WFLY-2388, which was fixed in 8.0.0.CR1 > However, it seems like with RequestDispatcher forward, the ORIGINAL ServletRequest object's getRequestURI returns the forwarded URI as the result, which is not correct. It is expected that the original ServletRequest object should retain its originating requested URI throughout the processing. > This seems to affect all the versions of Wildfly (tested on 8.1 and 9.0 alpha) > Take note that this has also been tested on JBoss AS 7 and tomcat 7, both have correctly retained the originating URI as expected even after dispatcher forwards -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:35:18 2014 From: issues at jboss.org (Jay Kumar SenSharma (JIRA)) Date: Tue, 11 Nov 2014 09:35:18 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4071) deploy and undeploy commands inside batch mode in domain mode cause missing deployment content In-Reply-To: References: Message-ID: Jay Kumar SenSharma created WFLY-4071: ----------------------------------------- Summary: deploy and undeploy commands inside batch mode in domain mode cause missing deployment content Key: WFLY-4071 URL: https://issues.jboss.org/browse/WFLY-4071 Project: WildFly Issue Type: Bug Components: Domain Management Affects Versions: 9.0.0.Alpha1 Reporter: Jay Kumar SenSharma Assignee: Brian Stansberry - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: {code} [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:35:19 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:35:19 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4071) deploy and undeploy commands inside batch mode in domain mode cause missing deployment content In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4071: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1162444 > deploy and undeploy commands inside batch mode in domain mode cause missing deployment content > ---------------------------------------------------------------------------------------------- > > Key: WFLY-4071 > URL: https://issues.jboss.org/browse/WFLY-4071 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Brian Stansberry > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:35:19 2014 From: issues at jboss.org (Jay Kumar SenSharma (JIRA)) Date: Tue, 11 Nov 2014 09:35:19 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4071) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kumar SenSharma updated WFLY-4071: -------------------------------------- Summary: the deployment content is deleted if first undeploy and then deploy the same application using CLI batch (was: deploy and undeploy commands inside batch mode in domain mode cause missing deployment content) > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-4071 > URL: https://issues.jboss.org/browse/WFLY-4071 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Brian Stansberry > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:35:19 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Tue, 11 Nov 2014 09:35:19 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4072) Unable to Enable JTA for a Datasource In-Reply-To: References: Message-ID: shinzey shinzey created WFLY-4072: ------------------------------------- Summary: Unable to Enable JTA for a Datasource Key: WFLY-4072 URL: https://issues.jboss.org/browse/WFLY-4072 Project: WildFly Issue Type: Bug Components: EE, EJB Affects Versions: 8.1.0.Final Environment: Windows 7 Java 8u25 WildFly 8.1.0.Final Reporter: shinzey shinzey Assignee: David Lloyd Priority: Critical Whenever trying to enable JTA, the following error is reported: Unknown error Unexpected HTTP response: 500 Request { "name" => "test", "user-name" => "test", "password" => "test", "security-domain" => "", "jndi-name" => "java:/datasource/test", "transaction-isolation" => "TRANSACTION_READ_COMMITTED", "new-connection-sql" => "", "connection-url" => "jdbc:derby://localhost:1527/test", "driver-class" => "org.apache.derby.jdbc.ClientDriver", "jta" => true, "pool-name" => "", "use-ccm" => false, "datasource-class" => "", "valid-connection-checker-class-name" => "", "check-valid-connection-sql" => "", "background-validation" => false, "background-validation-millis" => -1L, "validate-on-match" => false, "stale-connection-checker-class-name" => "", "exception-sorter-class-name" => "", "prepared-statements-cache-size" => -1L, "share-prepared-statements" => false, "enabled" => false, "driver-name" => "Derby_org.apache.derby.jdbc.ClientDriver_10_10", "operation" => "enable", "address" => [ ("subsystem" => "datasources"), ("data-source" => "test") ] } Response Internal Server Error { "outcome" => "failed", "failure-description" => "JBAS014750: Operation handler failed to complete", "rolled-back" => true } Due to this issue, EJB's transaction management does not work. I tested the same database on GlassFish and JTA works fine. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:35:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:35:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3974) Move 'Channel end notification received, closing channel' to DEBUG In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018827#comment-13018827 ] RH Bugzilla Integration commented on WFLY-3974: ----------------------------------------------- Dominik Pospisil changed the Status of [bug 1147506|https://bugzilla.redhat.com/show_bug.cgi?id=1147506] from POST to MODIFIED > Move 'Channel end notification received, closing channel' to DEBUG > ------------------------------------------------------------------ > > Key: WFLY-3974 > URL: https://issues.jboss.org/browse/WFLY-3974 > Project: WildFly > Issue Type: Enhancement > Components: Naming > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 9.0.0.Beta1 > > > When a remote jms queue is located the following is seen: > 2014-09-25 16:48:29,327 INFO [org.jboss.as.naming] (Remoting "jeev6dev01_200" task-1) JBAS011806: Notification de fin de canal re?ue, fermeture du canal Channel ID 0cb79bd5 (inbound) of Remoting connection 53a1933a to /10.23.132.245:57733 > This is due to org.jboss.as.naming.NamingLogger where the following is used: > @LogMessage(level=Logger.Level.INFO) > @Message(id=11806, value="Channel end notification received, closing channel %s") > public abstract void closingChannelOnChannelEnd(Channel paramChannel); > Changin this to > @LogMessage(level=Logger.Level.DEBUG) > Would ensure that an INFO log event is not seen every time a jms message is sent to the server. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:35:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:35:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3779) IllegalAccessException when a built-in normal-scoped bean defines a package-private no-arg constructor In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018826#comment-13018826 ] RH Bugzilla Integration commented on WFLY-3779: ----------------------------------------------- Dominik Pospisil changed the Status of [bug 1133962|https://bugzilla.redhat.com/show_bug.cgi?id=1133962] from POST to MODIFIED > IllegalAccessException when a built-in normal-scoped bean defines a package-private no-arg constructor > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-3779 > URL: https://issues.jboss.org/browse/WFLY-3779 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Reporter: Jozef Hartinger > Assignee: Jozef Hartinger > Fix For: 8.2.0.CR1, 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:35:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:35:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-154) Patching does not process subdirectories In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018828#comment-13018828 ] RH Bugzilla Integration commented on WFCORE-154: ------------------------------------------------ Dominik Pospisil changed the Status of [bug 1136365|https://bugzilla.redhat.com/show_bug.cgi?id=1136365] from POST to MODIFIED > Patching does not process subdirectories > ---------------------------------------- > > Key: WFCORE-154 > URL: https://issues.jboss.org/browse/WFCORE-154 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 1.0.0.Alpha9 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Alpha10 > > > If patched resource is in subdirectory of moduleRoot, it is not included as part of patch, even though it is present in patch zip. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:35:44 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:35:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-764) Enhance the security realm plug-in mechanism for client-cert / external verification. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018845#comment-13018845 ] RH Bugzilla Integration commented on WFLY-764: ---------------------------------------------- Dominik Pospisil changed the Status of [bug 1123505|https://bugzilla.redhat.com/show_bug.cgi?id=1123505] from NEW to ASSIGNED > Enhance the security realm plug-in mechanism for client-cert / external verification. > ------------------------------------------------------------------------------------- > > Key: WFLY-764 > URL: https://issues.jboss.org/browse/WFLY-764 > Project: WildFly > Issue Type: Task > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Labels: Realm_Management > Fix For: Awaiting Volunteers > > > Currently verification is just based on the defined trust store - this is to take it one step further and allow an optional additional verification. > As a first step will need to ensure we have a suitable Callback from the authenticator to the realm to verify the identity and then this can be passed on to the plug-in. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:35:45 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:35:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3580) Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018846#comment-13018846 ] RH Bugzilla Integration commented on WFLY-3580: ----------------------------------------------- Dominik Pospisil changed the Status of [bug 1123505|https://bugzilla.redhat.com/show_bug.cgi?id=1123505] from NEW to ASSIGNED > Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3580 > URL: https://issues.jboss.org/browse/WFLY-3580 > Project: WildFly > Issue Type: Bug > Components: Domain Management, EJB > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection. This makes it impossible to get the certificate for use in a custom login module. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:35:46 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:35:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018848#comment-13018848 ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Dominik Pospisil changed the Status of [bug 1149621|https://bugzilla.redhat.com/show_bug.cgi?id=1149621] from NEW to ASSIGNED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:00 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:00 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018874#comment-13018874 ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Enrique Gonzalez Martinez changed the Status of [bug 1149621|https://bugzilla.redhat.com/show_bug.cgi?id=1149621] from ASSIGNED to POST > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:08 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 11 Nov 2014 09:36:08 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-240) We need something similar to StandardConfigsXMLValidationUnitTestCase in Core In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-240: --------------------------------------- Summary: We need something similar to StandardConfigsXMLValidationUnitTestCase in Core Key: WFCORE-240 URL: https://issues.jboss.org/browse/WFCORE-240 Project: WildFly Core Issue Type: Feature Request Components: Test Suite Reporter: Darran Lofthouse Assignee: Tomaz Cerar Fix For: 1.0.0.Alpha13 One feature of this test is that it validates that schemas are correct according to the schema schema, presently we only find out about errors in schemas when the wildfly testsuite is executed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:35 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Tue, 11 Nov 2014 09:36:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1233) Make pool lock across all credentials In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesper Pedersen resolved JBJCA-1233. ------------------------------------ Resolution: Done > Make pool lock across all credentials > ------------------------------------- > > Key: JBJCA-1233 > URL: https://issues.jboss.org/browse/JBJCA-1233 > Project: IronJacamar > Issue Type: Task > Components: Core > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.2.1.Final > > > Previous pool lock was per crendential leading to more tricky setup in cases where multiple credentials were used per pool -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:37 2014 From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA)) Date: Tue, 11 Nov 2014 09:36:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3290) Cannot use a cluster name other than "ejb" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Panagiotis Sotiropoulos updated WFLY-3290: ------------------------------------------ Assignee: Paul Ferraro (was: Panagiotis Sotiropoulos) > Cannot use a cluster name other than "ejb" > ------------------------------------------ > > Key: WFLY-3290 > URL: https://issues.jboss.org/browse/WFLY-3290 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Chris Stillwell > Assignee: Paul Ferraro > Priority: Critical > Attachments: helloworld-test.zip > > > When deploying a clustered session bean the cluster will form only if the cluster name is "ejb". If the standalone-ha.xml is modified to use a different cluster name then the cluster will not form. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:38 2014 From: issues at jboss.org (David Castro (JIRA)) Date: Tue, 11 Nov 2014 09:36:38 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-141) Failed to transform class with name com.some.class. Reason: null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018934#comment-13018934 ] David Castro commented on JASSIST-141: -------------------------------------- Searching differences between the last non crashing code i found this: I'm trying to mock a class A wich extends class B inside the B class, I got: final boolean top = placement != BOTTOM || !sel; final boolean left = placement != RIGHT || !sel; BOTTOM and RIGHT are static final strings and sel is a boolean value if I replace these two lines with: final boolean top = !BOTTOM.equals(placement) || !sel; final boolean left = !RIGHT.equals(placement) || !sel; when I define the mock of the first class extending this one i got the crash named before... > Failed to transform class with name com.some.class. Reason: null > ---------------------------------------------------------------- > > Key: JASSIST-141 > URL: https://issues.jboss.org/browse/JASSIST-141 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.14.0.GA > Environment: eclipse, powermock 1.4.8, easymock 3, junit 4.8, javassist 3.14.0.GA > Reporter: Andreas Don'tAskDon'tTell > Assignee: Shigeru Chiba > Labels: mapmaker, powermock > > Hi, > i get this error while using the @PrepareForTest() annotation from the powermock framework. > This framework uses javassist for bytecode manipulation and i think it's more a javassist bug then a powermock bug. > the code i try to parse is 2500 lines long (i know bad bad bad code but it's not mine, i only need to test it). i do not want to post all. If you could help me to debug the hole file with javassist to find the methodes or statments that produces this error, i am happy to do so. Is there some debuging level or something to check where javassist crashes? > Thankyou for now :D > Yours, > Andreas > and here the stacktrace: > java.lang.IllegalStateException: Failed to transform class with name com.some.class. Reason: null > at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:207) > at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:145) > at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:65) > at java.lang.ClassLoader.loadClass(ClassLoader.java:248) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:247) > at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:95) > at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:107) > at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31) > at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:370) > at sun.reflect.annotation.AnnotationParser.parseClassValue(AnnotationParser.java:351) > at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653) > at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460) > at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286) > at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222) > at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69) > at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52) > at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070) > at java.lang.Class.getAnnotations(Class.java:3050) > at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.classAnnotations(PowerMockJUnit44RunnerDelegateImpl.java:163) > at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getDescription(PowerMockJUnit44RunnerDelegateImpl.java:155) > at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.getDescription(JUnit4TestSuiteChunkerImpl.java:172) > at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.getDescription(AbstractCommonPowerMockRunner.java:47) > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.sendTree(JUnit4TestClassReference.java:38) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.sendTrees(RemoteTestRunner.java:476) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:464) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) > Caused by: java.lang.NullPointerException > at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:888) > at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:822) > at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:620) > at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:102) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:182) > at javassist.bytecode.stackmap.MapMaker.traceException(MapMaker.java:213) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:175) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > ===================================================================================================================== > 243 times this line : at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192) > ===================================================================================================================== > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:141) > at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:96) > at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:416) > at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:398) > at javassist.expr.ExprEditor.doit(ExprEditor.java:112) > at javassist.CtClassType.instrument(CtClassType.java:1384) > at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:77) > at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203) > ... 28 more -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 11 Nov 2014 09:36:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-645) Accumulate returned fact causing NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-645: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Accumulate returned fact causing NPE > ------------------------------------ > > Key: DROOLS-645 > URL: https://issues.jboss.org/browse/DROOLS-645 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta2 > Environment: Mac OSX (maverick) > Reporter: Roger Lefebvre > Assignee: Mario Fusco > Attachments: RetryOldestCallTimeAccumulateFunction.java, RetryOldestCallTimeAccumulateFunction.java > > > The issue is discussed in https://groups.google.com/forum/?hl=en-GB#!topic/drools-usage/aZU5mXSgHMI. > Here is the gist of it.... > I changed the accumulator to the following and it worked: > accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), $message:oldestRetry( $sm )) > The previous approach was this: > $message:StatusMessage() from accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), oldestRetry( $sm )) > which I thought was the correct or acceptable syntax option. Is there something I have overlooked in the second one ("from"??). It does give me a StatusMessage object but it lacks the underlying properties to allow the subsequent modify to work. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3841) double :remove of connection-property from a DS leave it in wrong state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018936#comment-13018936 ] RH Bugzilla Integration commented on WFLY-3841: ----------------------------------------------- Paul Gier changed the Status of [bug 1024239|https://bugzilla.redhat.com/show_bug.cgi?id=1024239] from MODIFIED to ON_QA > double :remove of connection-property from a DS leave it in wrong state > ----------------------------------------------------------------------- > > Key: WFLY-3841 > URL: https://issues.jboss.org/browse/WFLY-3841 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Priority: Critical > Fix For: 9.0.0.CR1 > > > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:add(value=foo) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone at localhost:9990 /] :reload > { > "outcome" => "success", > "result" => undefined > } > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service jboss.data-source-config.ExampleDS.connection-properties.foo was depended upon by service jboss.data-source-config.ExampleDS", > "rolled-back" => true > } > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:remove > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:test-connection-in-pool > { > "outcome" => "failed", > "failure-description" => "WFLYJCA0040: failed to invoke operation: WFLYJCA0042: failed to match pool. Check JndiName: java:jboss/datasources/ExampleDS", > "rolled-back" => true > } -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-57) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018937#comment-13018937 ] RH Bugzilla Integration commented on WFCORE-57: ----------------------------------------------- Paul Gier changed the Status of [bug 1070214|https://bugzilla.redhat.com/show_bug.cgi?id=1070214] from MODIFIED to ON_QA > Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* > -------------------------------------------------------------------------------- > > Key: WFCORE-57 > URL: https://issues.jboss.org/browse/WFCORE-57 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Harald Pehl > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > When executing > {code} > /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2) > {code} > the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}: > {code} > ... > "acl" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > "model-description" => {"classic" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > ... > "operations" => undefined, > "children" => { > "acl-module" => { > "description" => "ACL module", > "model-description" => {"*" => { > "description" => "List of authentication modules", > ... > "operations" => undefined, > "children" => {} > }} > }, > "login-module" => { > "description" => "Login module", > "model-description" => {"*" => undefined} > } > } > }} > }, > ... > {code} > However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4060) Intermittent failures on SendMessage testcase when running with JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018938#comment-13018938 ] RH Bugzilla Integration commented on WFLY-4060: ----------------------------------------------- Paul Gier changed the Status of [bug 1160761|https://bugzilla.redhat.com/show_bug.cgi?id=1160761] from MODIFIED to ON_QA > Intermittent failures on SendMessage testcase when running with JTS > ------------------------------------------------------------------- > > Key: WFLY-4060 > URL: https://issues.jboss.org/browse/WFLY-4060 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ond?ej Chaloupka > Assignee: Ond?ej Chaloupka > > During testing EAP I was hitting intermittent failures on SendMessageTestscase which was caused by timing issues. > There is a bit more explanation of reasons at bz: https://bugzilla.redhat.com/show_bug.cgi?id=1160761 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3580) Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018939#comment-13018939 ] RH Bugzilla Integration commented on WFLY-3580: ----------------------------------------------- Paul Gier changed the Status of [bug 953200|https://bugzilla.redhat.com/show_bug.cgi?id=953200] from MODIFIED to ON_QA > Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3580 > URL: https://issues.jboss.org/browse/WFLY-3580 > Project: WildFly > Issue Type: Bug > Components: Domain Management, EJB > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection. This makes it impossible to get the certificate for use in a custom login module. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-764) Enhance the security realm plug-in mechanism for client-cert / external verification. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018940#comment-13018940 ] RH Bugzilla Integration commented on WFLY-764: ---------------------------------------------- Paul Gier changed the Status of [bug 953200|https://bugzilla.redhat.com/show_bug.cgi?id=953200] from MODIFIED to ON_QA > Enhance the security realm plug-in mechanism for client-cert / external verification. > ------------------------------------------------------------------------------------- > > Key: WFLY-764 > URL: https://issues.jboss.org/browse/WFLY-764 > Project: WildFly > Issue Type: Task > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Labels: Realm_Management > Fix For: Awaiting Volunteers > > > Currently verification is just based on the defined trust store - this is to take it one step further and allow an optional additional verification. > As a first step will need to ensure we have a suitable Callback from the authenticator to the realm to verify the identity and then this can be passed on to the plug-in. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-220) cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018941#comment-13018941 ] RH Bugzilla Integration commented on WFCORE-220: ------------------------------------------------ Paul Gier changed the Status of [bug 1103620|https://bugzilla.redhat.com/show_bug.cgi?id=1103620] from MODIFIED to ON_QA > cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored > ---------------------------------------------------------------------- > > Key: WFCORE-220 > URL: https://issues.jboss.org/browse/WFCORE-220 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Scripts > Reporter: Alexey Loubyansky > Assignee: James Perkins > Fix For: 1.0.0.Alpha12 > > > E.g. ./jboss-cli.sh -Djboss.cli.config=/jboss-cli.xml > The system property won't be set, instead the argument will treated as simply a command line argument. > This has to be fixed in the scripts themselves launching the CLI. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:43 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018943#comment-13018943 ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Paul Gier changed the Status of [bug 1139202|https://bugzilla.redhat.com/show_bug.cgi?id=1139202] from MODIFIED to ON_QA > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:43 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3847) AS7BindingRegistry does not respect the SPI contract In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018944#comment-13018944 ] RH Bugzilla Integration commented on WFLY-3847: ----------------------------------------------- Paul Gier changed the Status of [bug 1124178|https://bugzilla.redhat.com/show_bug.cgi?id=1124178] from MODIFIED to ON_QA > AS7BindingRegistry does not respect the SPI contract > ---------------------------------------------------- > > Key: WFLY-3847 > URL: https://issues.jboss.org/browse/WFLY-3847 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > Fix For: 9.0.0.Alpha1 > > > The implementation of AS7BindingRegistry#lookup always return null. > This method is called by HornetQ when JNDI entries for its resources > are updated using its own management API. > We advise against using it in WildFly (and use WildFly own management API) but we must still respect the SPI contract for this method. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:45 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3905) POJO JAX-WS endpoints should not be processed if packaged in EJB-jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018947#comment-13018947 ] RH Bugzilla Integration commented on WFLY-3905: ----------------------------------------------- Paul Gier changed the Status of [bug 1147657|https://bugzilla.redhat.com/show_bug.cgi?id=1147657] from MODIFIED to ON_QA > POJO JAX-WS endpoints should not be processed if packaged in EJB-jar > -------------------------------------------------------------------- > > Key: WFLY-3905 > URL: https://issues.jboss.org/browse/WFLY-3905 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Kyle Lape > Assignee: Kyle Lape > Fix For: 9.0.0.Beta1 > > > If a POJO is defined like this in an EJB-jar: > {code:java} > package com.redhat.gss.ws; > @javax.jws.WebService > public class HelloService { > public String sayHello() { > return "Hello World!"; > } > } > {code} > Deployment structure: > {noformat} > klape at localhost ws-java.jar$ tree > . > ??? com > ??? ??? redhat > ??? ??? gss > ??? ??? ws > ??? ??? HelloService.java > ??? META-INF > ??? MANIFEST.MF > 5 directories, 2 files > klape at localhost ws-java.jar$ > {noformat} > Upon deployment, you get this in the log: > {noformat} > 16:52:51,372 INFO [org.jboss.ws.cxf.metadata] (MSC service thread 1-7) JBWS024061: Adding service endpoint metadata: id=com.redhat.gss.ws.HelloService > address=http://localhost:8080/ws-java/HelloService > implementor=com.redhat.gss.ws.HelloService > serviceName={http://ws.gss.redhat.com/}HelloServiceService > portName={http://ws.gss.redhat.com/}HelloServicePort > annotationWsdlLocation=null > wsdlLocationOverride=null > mtomEnabled=false > 16:52:51,571 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-7) Creating Service {http://ws.gss.redhat.com/}HelloServiceService from class com.redhat.gss.ws.HelloService > 16:52:51,879 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-7) Setting the server's publish address to be http://localhost:8080/ws-java/HelloService > 16:52:51,925 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-7) JBWS024074: WSDL published to: file:/home/remote/klape/work/archives/wildfly-8.1.0.Final/standalone/data/wsdl/ws-java.jar/HelloServiceService.wsdl > {noformat} > Yet when you try to get the WSDL at {{http://localhost:8080/ws-java/HelloService?wsdl}} (pulled from the metadata in the log), you get a 404 error. > JBossWS should not be trying to deploy the POJO endpoint from within an EJB-jar. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:45 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018949#comment-13018949 ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Paul Gier changed the Status of [bug 1149618|https://bugzilla.redhat.com/show_bug.cgi?id=1149618] from MODIFIED to ON_QA > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:46 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018951#comment-13018951 ] RH Bugzilla Integration commented on WFCORE-160: ------------------------------------------------ Paul Gier changed the Status of [bug 1145960|https://bugzilla.redhat.com/show_bug.cgi?id=1145960] from MODIFIED to ON_QA > Bash scripts should not attempt to expand argument properties > ------------------------------------------------------------- > > Key: WFCORE-160 > URL: https://issues.jboss.org/browse/WFCORE-160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha10 > > > Scripts that parse the command line arguments use a pattern like > {code} > while [ "$#" -gt 0 ] > do > case "$1" in > *) > CLI_OPTS="$CLI_OPTS \"$1\"" > ;; > esac > shift > done > {code} > The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:48 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:48 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-158) Handlers should not be allowed to be removed if they're assigned to another handler or logger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018954#comment-13018954 ] RH Bugzilla Integration commented on WFCORE-158: ------------------------------------------------ Paul Gier changed the Status of [bug 1007333|https://bugzilla.redhat.com/show_bug.cgi?id=1007333] from MODIFIED to ON_QA > Handlers should not be allowed to be removed if they're assigned to another handler or logger > --------------------------------------------------------------------------------------------- > > Key: WFCORE-158 > URL: https://issues.jboss.org/browse/WFCORE-158 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha12 > > > Handlers can currently be removed even if the handler is assigned to a logger or another handler. This allows an invalid {{logging.properties}} file to be written and will fail to start the server on the next boot. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:48 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 11 Nov 2014 09:36:48 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-159) Handlers can be created with the same name as an existing handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018956#comment-13018956 ] RH Bugzilla Integration commented on WFCORE-159: ------------------------------------------------ Paul Gier changed the Status of [bug 1151256|https://bugzilla.redhat.com/show_bug.cgi?id=1151256] from MODIFIED to ON_QA > Handlers can be created with the same name as an existing handler > ----------------------------------------------------------------- > > Key: WFCORE-159 > URL: https://issues.jboss.org/browse/WFCORE-159 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha12 > > > Handlers can be created with the same name as an existing handler. This was done to reconfigure differences in the logging subsystem XML and the logging.properties file. The problem is it will replace a handler during an {{ADD}} operation if the same name is used on another parent resource. > {code} > /subsystem=logging/async-handler=CONSOLE:add(queue-length=10,overflow-action=BLOCK) > {code} > This will replace the default console handler with the new one keeping the existing console-handler resource. The next boot also fails with no indication on the console. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:50 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 11 Nov 2014 09:36:50 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-241) HTTP Management interface, enabled true in schema, false in model definition. In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-241: --------------------------------------- Summary: HTTP Management interface, enabled true in schema, false in model definition. Key: WFCORE-241 URL: https://issues.jboss.org/browse/WFCORE-241 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha13 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:53 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 11 Nov 2014 09:36:53 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-54) Support for stronger hashes as alternatives to MD5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018961#comment-13018961 ] David Lloyd commented on ELY-54: -------------------------------- Checklist: * Rename md5digest package to just digest * Dissociate from AbstractSasl* infrastructure which only supports single mechanisms and add additonal hashes * Rename MD5Digest* * Rename DigestMD5Password* to DigestPassword* * Add multi algorithm support to digest password impl * Additional hashes to support: ** SHA-1 (http://tools.ietf.org/html/rfc5843) ** SHA-256 (http://tools.ietf.org/html/rfc5843) ** SHA-512 (http://tools.ietf.org/html/rfc5843) > Support for stronger hashes as alternatives to MD5 > -------------------------------------------------- > > Key: ELY-54 > URL: https://issues.jboss.org/browse/ELY-54 > Project: WildFly Elytron > Issue Type: Feature Request > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > > Presently Digest authentication is based on MD5 - however we should either update the mechanism or add new mechanisms to support the use of stronger hashes. > As this library is used both client and server side installations that require the stronger hashes can just ensure the client and server have the latest version of this library - installations that still require interaction with MD5 will need to ensure that it is still available as a mechanism. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:55 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 11 Nov 2014 09:36:55 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved WFLY-4071 to WFCORE-242: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-242 (was: WFLY-4071) Affects Version/s: (was: 9.0.0.Alpha1) Component/s: Domain Management (was: Domain Management) > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Brian Stansberry > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:56 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 11 Nov 2014 09:36:56 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-242: ------------------------------------ Component/s: CLI > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Brian Stansberry > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:57 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 11 Nov 2014 09:36:57 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13018964#comment-13018964 ] Brian Stansberry commented on WFCORE-242: ----------------------------------------- Adding --force to the "deploy" command will allow you to skip the "undeploy" command. > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Brian Stansberry > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:36:59 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Tue, 11 Nov 2014 09:36:59 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-242: --------------------------------------- Assignee: Emmanuel Hugonnet (was: Brian Stansberry) Emmanuel, I'm assigning this to you as it's so related to the content repo gc issues you've tackled. It's possible this is a CLI issue though. The "undeploy" and "deploy" commands are high level commands, not low level ops. So it's possible the actual low level commands that the CLI sends out are happening in a different order than you'd expect from looking at the batch in the description. I suggest you test that first by tracking what ops the server receives. > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:37:01 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 11 Nov 2014 09:37:01 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-645) Accumulate returned fact causing NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-645. -------------------------------- Resolution: Cannot Reproduce Bug I tried both accumulate syntax with the test case I am pasting below and they both work correctly. I cannot reproduce this issue, but if there's something that I am missing with my reproducer please let me know and eventually reopen this ticket. Moreover there's another couple of things to notice: 1. Apparently the accumulate class you attached has a bug. Indeed it throws a CCE saying: Caused by: java.lang.ClassCastException: org.drools.compiler.integrationtests.AccumulateTest$StatusMessage cannot be cast to java.util.List at org.drools.compiler.integrationtests.AccumulateTest$RetryOldestCallTimeAccumulateFunction.accumulate(AccumulateTest.java:2853) As you can see in my test case I changed data.addAll((List) value); with data.add((StatusMessage) value); let me know if this is ok and corresponds to what you wanted to achieve. 2. Apparently you're using that custom accumulate only to retrieve the StatusMessage with the lowest callTime. If that's true there's a more efficient way to obtain the same result with a simple not as it follows: $message: StatusMessage( /* add constraints here */ ) not StatusMessage( callTime.before($message.callTime) ) {code} @Test public void testSortingAccumulate() throws Exception { String drl = "package org.foo.bar\n" + "global java.util.List list\n" + "import " + StatusMessage.class.getCanonicalName() + "\n" + "import accumulate " + RetryOldestCallTimeAccumulateFunction.class.getCanonicalName() + " oldestRetry\n" + "rule X when\n" + //" accumulate($sm: StatusMessage(campaignName==\"test\"), $message:oldestRetry( $sm )) \n" + " $message: StatusMessage() from accumulate($sm: StatusMessage(campaignName==\"test\"), oldestRetry( $sm )) \n" + "then\n" + " modify($message) { setCampaignName(\"notest\") };" + "end\n"; KieSession ksession = new KieHelper().addContent(drl, ResourceType.DRL) .build() .newKieSession(); List list = new ArrayList(); ksession.setGlobal("list", list); ksession.insert(new StatusMessage("test", 3)); ksession.insert(new StatusMessage("test", 2)); ksession.insert(new StatusMessage("test", 4)); ksession.fireAllRules(); assertEquals(1, list.size()); assertEquals(2, list.get(0).getCallTime()); } public static class StatusMessage { private String campaignName; private final int callTime; public StatusMessage(String campaignName, int callTime) { this.campaignName = campaignName; this.callTime = callTime; } public int getCallTime() { return callTime; } public String getCampaignName() { return campaignName; } public void setCampaignName(String campaignName) { this.campaignName = campaignName; } } public static class RetryOldestCallTimeAccumulateFunction implements AccumulateFunction { private static final Comparator callTimeComparator = new Comparator() { @Override public int compare(StatusMessage s1, StatusMessage s2) { return s1.getCallTime() - s2.getCallTime(); } }; @Override public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException { } @Override public void writeExternal(ObjectOutput out) throws IOException { } /* (non-Javadoc) * @see org.kie.api.runtime.rule.AccumulateFunction#createContext() */ @Override public Serializable createContext() { return new ArrayList(); } /* (non-Javadoc) * @see org.kie.api.runtime.rule.AccumulateFunction#init(java.lang.Object) */ @Override public void init(Serializable context) throws Exception { @SuppressWarnings("unchecked") List data = (List) context; data.clear(); } /* (non-Javadoc) * @see org.kie.api.runtime.rule.AccumulateFunction#accumulate(java.lang.Object, java.lang.Object) */ @SuppressWarnings("unchecked") @Override public void accumulate(Serializable context, Object value) { List data = (List) context; // data.addAll((List) value); <-- CCE data.add((StatusMessage) value); } /* (non-Javadoc) * @see org.kie.api.runtime.rule.AccumulateFunction#reverse(java.lang.Object, java.lang.Object) */ @Override public void reverse(Serializable context, Object value) throws Exception { } /* (non-Javadoc) * @see org.kie.api.runtime.rule.AccumulateFunction#getResult(java.lang.Object) */ @Override public Object getResult(Serializable context) throws Exception { @SuppressWarnings("unchecked") List data = (List) context; if (data.size() > 1) { Collections.sort(data, callTimeComparator); } return data.get(0); } /** * (non-Javadoc) * * @see org.kie.api.runtime.rule.AccumulateFunction#supportsReverse() */ @Override public boolean supportsReverse() { return false; } /** * {@inheritDoc} */ @Override public Class getResultType() { return StatusMessage.class; } } {code} > Accumulate returned fact causing NPE > ------------------------------------ > > Key: DROOLS-645 > URL: https://issues.jboss.org/browse/DROOLS-645 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta2 > Environment: Mac OSX (maverick) > Reporter: Roger Lefebvre > Assignee: Mario Fusco > Attachments: RetryOldestCallTimeAccumulateFunction.java, RetryOldestCallTimeAccumulateFunction.java > > > The issue is discussed in https://groups.google.com/forum/?hl=en-GB#!topic/drools-usage/aZU5mXSgHMI. > Here is the gist of it.... > I changed the accumulator to the following and it worked: > accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), $message:oldestRetry( $sm )) > The previous approach was this: > $message:StatusMessage() from accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), oldestRetry( $sm )) > which I thought was the correct or acceptable syntax option. Is there something I have overlooked in the second one ("from"??). It does give me a StatusMessage object but it lacks the underlying properties to allow the subsequent modify to work. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:58:12 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 11 Nov 2014 09:58:12 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not persisting via CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar resolved WFLY-2376. ------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done This was fixed in WFCORE-216 which is in core 1.0.0.Alpha12 that was integrated to master. > DataSource properties are not persisting via CLI > ------------------------------------------------ > > Key: WFLY-2376 > URL: https://issues.jboss.org/browse/WFLY-2376 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Jay Kumar SenSharma > Assignee: Stefano Maestri > Fix For: 9.0.0.Beta1 > > > - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration: > {quote} > ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" > "stale-connection-checker-properties" => { > "type" => OBJECT, > "description" => "The stale connection checker properties", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "reauth-plugin-properties" => { > "type" => OBJECT, > "description" => "The properties for the reauthentication plugin", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "exception-sorter-properties" => { > "type" => OBJECT, > "description" => "The exception sorter properties", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {quote} > - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource. > ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})" > - The Generated DataSource looks like following: > ${quote} > > jdbc:oracle:thin:@DBHostName:1521:DBName > ojdbc6.jar > select 1 from dual > > user > pass > > > > select 2 from dual > > > ${quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 11 09:58:18 2014 From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA)) Date: Tue, 11 Nov 2014 09:58:18 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3290) Cannot use a cluster name other than "ejb" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Panagiotis Sotiropoulos reassigned WFLY-3290: --------------------------------------------- Assignee: Panagiotis Sotiropoulos (was: Paul Ferraro) > Cannot use a cluster name other than "ejb" > ------------------------------------------ > > Key: WFLY-3290 > URL: https://issues.jboss.org/browse/WFLY-3290 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Chris Stillwell > Assignee: Panagiotis Sotiropoulos > Priority: Critical > Attachments: helloworld-test.zip > > > When deploying a clustered session bean the cluster will form only if the cluster name is "ejb". If the standalone-ha.xml is modified to use a different cluster name then the cluster will not form. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:05 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Wed, 12 Nov 2014 03:01:05 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-620) Interval rule consequence actions not processed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-620. -------------------------------- Fix Version/s: 6.2.0.CR2 Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/a0df4a8a4 > Interval rule consequence actions not processed > ----------------------------------------------- > > Key: DROOLS-620 > URL: https://issues.jboss.org/browse/DROOLS-620 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta1 > Environment: MacBook Pro, OS X 10.9.5 > Reporter: Roger Lefebvre > Assignee: Mario Fusco > Fix For: 6.2.0.CR2 > > > Actions defined in the consequence of a rule with an defined interval (e.g. cron) are not processed by the system. Inserted facts, modified fields and pushed agenda groups are not consumed resulting in other rules not being fired. If you execute fireAllRules from code, it will then process the consequence actions. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:07 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Wed, 12 Nov 2014 03:01:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4057) jboss-cli.bat stops working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Loubyansky resolved WFLY-4057. ------------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done Thanks for the confirmation! > jboss-cli.bat stops working > --------------------------- > > Key: WFLY-4057 > URL: https://issues.jboss.org/browse/WFLY-4057 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 9.0.0.Beta1 > Reporter: Juergen Zimmermann > Assignee: Alexey Loubyansky > Fix For: 9.0.0.Beta1 > > > I compiled the latest snapshot for 9.0.0.Alpha2. However, jboss-cli.bat doesn't work anymore. When I compiled the snapshot last week (Wed. 10/30/14 ?) jboss-cli.bat was working fine. Here is an example for the broken jboss-cli.bat: > {code} > jboss-cli.bat -c --command=:shutdown > ':shutdown' is assumed to be a command(s) but the commands to execute have been specified by another argument: [--command] > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:10 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Wed, 12 Nov 2014 03:01:10 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1234) Set to 0 for CRI based pools In-Reply-To: References: Message-ID: Jesper Pedersen created JBJCA-1234: -------------------------------------- Summary: Set to 0 for CRI based pools Key: JBJCA-1234 URL: https://issues.jboss.org/browse/JBJCA-1234 Project: IronJacamar Issue Type: Task Components: Deployer Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.1.10.Final, 1.2.1.Final We need to set the to 0 for CRI based pools to make sure that they can be removed based on their capacity decrementer policy -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:15 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 03:01:15 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not persisting via CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019026#comment-13019026 ] RH Bugzilla Integration commented on WFLY-2376: ----------------------------------------------- Tomaz Cerar changed the Status of [bug 1023064|https://bugzilla.redhat.com/show_bug.cgi?id=1023064] from ASSIGNED to POST > DataSource properties are not persisting via CLI > ------------------------------------------------ > > Key: WFLY-2376 > URL: https://issues.jboss.org/browse/WFLY-2376 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Jay Kumar SenSharma > Assignee: Stefano Maestri > Fix For: 9.0.0.Beta1 > > > - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration: > {quote} > ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" > "stale-connection-checker-properties" => { > "type" => OBJECT, > "description" => "The stale connection checker properties", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "reauth-plugin-properties" => { > "type" => OBJECT, > "description" => "The properties for the reauthentication plugin", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "exception-sorter-properties" => { > "type" => OBJECT, > "description" => "The exception sorter properties", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {quote} > - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource. > ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})" > - The Generated DataSource looks like following: > ${quote} > > jdbc:oracle:thin:@DBHostName:1521:DBName > ojdbc6.jar > select 1 from dual > > user > pass > > > > select 2 from dual > > > ${quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:15 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 03:01:15 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-216) Add ModelValidator to ensure resource model is correct In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019027#comment-13019027 ] RH Bugzilla Integration commented on WFCORE-216: ------------------------------------------------ Tomaz Cerar changed the Status of [bug 1023064|https://bugzilla.redhat.com/show_bug.cgi?id=1023064] from ASSIGNED to POST > Add ModelValidator to ensure resource model is correct > ------------------------------------------------------ > > Key: WFCORE-216 > URL: https://issues.jboss.org/browse/WFCORE-216 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stefano Maestri > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha12 > > > Currently there is no validation of "requires" and "alternatives" that are specified in attribute metadata / AttributeDefinition > ModelValidator should be added as extra step handler that executes on end of MODEL phase to ensure resource model is correct. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:17 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 03:01:17 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-161) JMX monitoring is extremely memory inefficient In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019030#comment-13019030 ] RH Bugzilla Integration commented on WFCORE-161: ------------------------------------------------ Panagiotis Sotiropoulos changed the Status of [bug 1154868|https://bugzilla.redhat.com/show_bug.cgi?id=1154868] from NEW to ASSIGNED > JMX monitoring is extremely memory inefficient > ---------------------------------------------- > > Key: WFCORE-161 > URL: https://issues.jboss.org/browse/WFCORE-161 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Koen Janssens > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha11 > > > When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created. > A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class. > More background on associated forum thread -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:17 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Wed, 12 Nov 2014 03:01:17 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1234) Set to 0 for CRI based pools In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesper Pedersen resolved JBJCA-1234. ------------------------------------ Resolution: Done > Set to 0 for CRI based pools > -------------------------------------------- > > Key: JBJCA-1234 > URL: https://issues.jboss.org/browse/JBJCA-1234 > Project: IronJacamar > Issue Type: Task > Components: Deployer > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.1.10.Final, 1.2.1.Final > > > We need to set the to 0 for CRI based pools to make sure that they can be removed based on their capacity decrementer policy -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:21 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Wed, 12 Nov 2014 03:01:21 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-243) Not started servers need a placeholder resource when added In-Reply-To: References: Message-ID: Alexey Loubyansky created WFCORE-243: ---------------------------------------- Summary: Not started servers need a placeholder resource when added Key: WFCORE-243 URL: https://issues.jboss.org/browse/WFCORE-243 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha12 Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky In ServerAddHandler where the server resource is created, a placeholder should be added. I.e. instead of context.createResource(...) below context.addStep(runningServerAdd, new OperationStepHandler() { @Override public void execute(final OperationContext context, final ModelNode operation) throws OperationFailedException { context.createResource(PathAddress.EMPTY_ADDRESS); context.stepCompleted(); } }, OperationContext.Stage.MODEL, true); context.addResource(PathAddress.EMPTY_ADDRESS, PlaceholderResource.INSTANCE) should be used instead. Otherwise, servers that are not started at boot will be missing runtime proxies and will be considered as parts of the persistent model. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:26 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Wed, 12 Nov 2014 03:01:26 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4072) Unable to Enable JTA for a Datasource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesper Pedersen updated WFLY-4072: ---------------------------------- Assignee: Stefano Maestri (was: David Lloyd) Component/s: JCA (was: EE) (was: EJB) > Unable to Enable JTA for a Datasource > ------------------------------------- > > Key: WFLY-4072 > URL: https://issues.jboss.org/browse/WFLY-4072 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Stefano Maestri > Priority: Critical > Labels: Datasource, JTA, ejb, wildfly > > Whenever trying to enable JTA, the following error is reported: > Unknown error > Unexpected HTTP response: 500 > Request > { > "name" => "test", > "user-name" => "test", > "password" => "test", > "security-domain" => "", > "jndi-name" => "java:/datasource/test", > "transaction-isolation" => "TRANSACTION_READ_COMMITTED", > "new-connection-sql" => "", > "connection-url" => "jdbc:derby://localhost:1527/test", > "driver-class" => "org.apache.derby.jdbc.ClientDriver", > "jta" => true, > "pool-name" => "", > "use-ccm" => false, > "datasource-class" => "", > "valid-connection-checker-class-name" => "", > "check-valid-connection-sql" => "", > "background-validation" => false, > "background-validation-millis" => -1L, > "validate-on-match" => false, > "stale-connection-checker-class-name" => "", > "exception-sorter-class-name" => "", > "prepared-statements-cache-size" => -1L, > "share-prepared-statements" => false, > "enabled" => false, > "driver-name" => "Derby_org.apache.derby.jdbc.ClientDriver_10_10", > "operation" => "enable", > "address" => [ > ("subsystem" => "datasources"), > ("data-source" => "test") > ] > } > Response > Internal Server Error > { > "outcome" => "failed", > "failure-description" => "JBAS014750: Operation handler failed to complete", > "rolled-back" => true > } > Due to this issue, EJB's transaction management does not work. I tested the same database on GlassFish and JTA works fine. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:28 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 03:01:28 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-764) Enhance the security realm plug-in mechanism for client-cert / external verification. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019046#comment-13019046 ] RH Bugzilla Integration commented on WFLY-764: ---------------------------------------------- Dominik Pospisil changed the Status of [bug 1123505|https://bugzilla.redhat.com/show_bug.cgi?id=1123505] from ASSIGNED to POST > Enhance the security realm plug-in mechanism for client-cert / external verification. > ------------------------------------------------------------------------------------- > > Key: WFLY-764 > URL: https://issues.jboss.org/browse/WFLY-764 > Project: WildFly > Issue Type: Task > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Labels: Realm_Management > Fix For: Awaiting Volunteers > > > Currently verification is just based on the defined trust store - this is to take it one step further and allow an optional additional verification. > As a first step will need to ensure we have a suitable Callback from the authenticator to the realm to verify the identity and then this can be passed on to the plug-in. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 03:01:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3580) Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019045#comment-13019045 ] RH Bugzilla Integration commented on WFLY-3580: ----------------------------------------------- Dominik Pospisil changed the Status of [bug 1123505|https://bugzilla.redhat.com/show_bug.cgi?id=1123505] from ASSIGNED to POST > Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3580 > URL: https://issues.jboss.org/browse/WFLY-3580 > Project: WildFly > Issue Type: Bug > Components: Domain Management, EJB > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection. This makes it impossible to get the certificate for use in a custom login module. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:34 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 12 Nov 2014 03:01:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-51) Add a PLAIN SaslClient implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd reassigned ELY-51: ------------------------------ Assignee: David Lloyd (was: Darran Lofthouse) > Add a PLAIN SaslClient implementation > ------------------------------------- > > Key: ELY-51 > URL: https://issues.jboss.org/browse/ELY-51 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:45 2014 From: issues at jboss.org (Daniel Bremiller (JIRA)) Date: Wed, 12 Nov 2014 03:01:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-646) remove package with duplicate Rule conditions infinite loop In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Bremiller updated DROOLS-646: ------------------------------------ Attachment: DroolsError.zip Attached sample project that produced error > remove package with duplicate Rule conditions infinite loop > ----------------------------------------------------------- > > Key: DROOLS-646 > URL: https://issues.jboss.org/browse/DROOLS-646 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 5.6.0.Final > Reporter: Daniel Bremiller > Assignee: Mark Proctor > Attachments: DroolsError.zip > > > Removal of a package containing two rules of the same condition that share a betanode causes an infinite loop. The Rules could be declared in seperate packages as well, when removing either would also reproduce the bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:45 2014 From: issues at jboss.org (Daniel Bremiller (JIRA)) Date: Wed, 12 Nov 2014 03:01:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-646) remove package with duplicate Rule conditions infinite loop In-Reply-To: References: Message-ID: Daniel Bremiller created DROOLS-646: --------------------------------------- Summary: remove package with duplicate Rule conditions infinite loop Key: DROOLS-646 URL: https://issues.jboss.org/browse/DROOLS-646 Project: Drools Issue Type: Bug Affects Versions: 5.6.0.Final, 5.5.0.Final Reporter: Daniel Bremiller Assignee: Mark Proctor Attachments: DroolsError.zip Removal of a package containing two rules of the same condition that share a betanode causes an infinite loop. The Rules could be declared in seperate packages as well, when removing either would also reproduce the bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:45 2014 From: issues at jboss.org (Daniel Bremiller (JIRA)) Date: Wed, 12 Nov 2014 03:01:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-646) remove package with duplicate Rule conditions infinite loop In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019075#comment-13019075 ] Daniel Bremiller commented on DROOLS-646: ----------------------------------------- I have verified the issue does not occur in Drools 5.3 or 5.4 > remove package with duplicate Rule conditions infinite loop > ----------------------------------------------------------- > > Key: DROOLS-646 > URL: https://issues.jboss.org/browse/DROOLS-646 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 5.6.0.Final > Reporter: Daniel Bremiller > Assignee: Mark Proctor > Attachments: DroolsError.zip > > > Removal of a package containing two rules of the same condition that share a betanode causes an infinite loop. The Rules could be declared in seperate packages as well, when removing either would also reproduce the bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:45 2014 From: issues at jboss.org (Daniel Bremiller (JIRA)) Date: Wed, 12 Nov 2014 03:01:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-646) remove package with duplicate Rule conditions infinite loop In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019076#comment-13019076 ] Daniel Bremiller commented on DROOLS-646: ----------------------------------------- The while loop in BetaNode.doRemove() is where the loop is occuring. > remove package with duplicate Rule conditions infinite loop > ----------------------------------------------------------- > > Key: DROOLS-646 > URL: https://issues.jboss.org/browse/DROOLS-646 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 5.6.0.Final > Reporter: Daniel Bremiller > Assignee: Mark Proctor > Attachments: DroolsError.zip > > > Removal of a package containing two rules of the same condition that share a betanode causes an infinite loop. The Rules could be declared in seperate packages as well, when removing either would also reproduce the bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:54 2014 From: issues at jboss.org (Ian Kent (JIRA)) Date: Wed, 12 Nov 2014 03:01:54 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-218) wildfly web management console hangs during deploy from cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019084#comment-13019084 ] Ian Kent commented on WFCORE-218: --------------------------------- I am using WildFly 8.1.0.Final. When I am deploying a war via jboss-cli the wildfly management console is not available. I just get a spinning icon. I used jvisual vm to connect to jmx of domain controller java process. service:jmx:http-remoting-jmx://[host]:9990 I did a thread dump using jvisualvm and it is attached. > wildfly web management console hangs during deploy from cli > ----------------------------------------------------------- > > Key: WFCORE-218 > URL: https://issues.jboss.org/browse/WFCORE-218 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha1 > Reporter: Ian Kent > Assignee: Brian Stansberry > Attachments: threaddump-1415735255304.tdump > > > We are running wildfly in domain mode with the following configuration. > host A running domain controlller > host B running host controller with one app sever > host C running host controller with one app server > host D running host controller with one app server > When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:57 2014 From: issues at jboss.org (Dawna Floyd (JIRA)) Date: Wed, 12 Nov 2014 03:01:57 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-647) memory leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawna Floyd updated DROOLS-647: ------------------------------- Attachment: DROOL_TEST.zip > memory leak > ----------- > > Key: DROOLS-647 > URL: https://issues.jboss.org/browse/DROOLS-647 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Reporter: Dawna Floyd > Assignee: Mark Proctor > Attachments: DROOL_TEST.zip > > > references to fact handles not being removed when objects are removed from memory. Converted our application from 5.0.1 to 6.1_Final and encountered memory leaks in the drools processing. Found references to defect 498 and checked out the 6.1.1 code based and built the source (the download package doesn't seem to have these fixes). The majority of leaks were corrected with this code line, however there still remains a memory leak when we run our defined rules. Even though a rule never fires, it's evaluation seems to hold onto beta memory forever and the test application will eventually run out of memory. I can provide a test program that highlights the leak. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:57 2014 From: issues at jboss.org (Dawna Floyd (JIRA)) Date: Wed, 12 Nov 2014 03:01:57 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-647) memory leak In-Reply-To: References: Message-ID: Dawna Floyd created DROOLS-647: ---------------------------------- Summary: memory leak Key: DROOLS-647 URL: https://issues.jboss.org/browse/DROOLS-647 Project: Drools Issue Type: Bug Affects Versions: 6.1.0.Final Reporter: Dawna Floyd Assignee: Mark Proctor Attachments: DROOL_TEST.zip references to fact handles not being removed when objects are removed from memory. Converted our application from 5.0.1 to 6.1_Final and encountered memory leaks in the drools processing. Found references to defect 498 and checked out the 6.1.1 code based and built the source (the download package doesn't seem to have these fixes). The majority of leaks were corrected with this code line, however there still remains a memory leak when we run our defined rules. Even though a rule never fires, it's evaluation seems to hold onto beta memory forever and the test application will eventually run out of memory. I can provide a test program that highlights the leak. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:01:56 2014 From: issues at jboss.org (Ian Kent (JIRA)) Date: Wed, 12 Nov 2014 03:01:56 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-218) wildfly web management console hangs during deploy from cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ian Kent updated WFCORE-218: ---------------------------- Attachment: threaddump-1415735255304.tdump > wildfly web management console hangs during deploy from cli > ----------------------------------------------------------- > > Key: WFCORE-218 > URL: https://issues.jboss.org/browse/WFCORE-218 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha1 > Reporter: Ian Kent > Assignee: Brian Stansberry > Attachments: threaddump-1415735255304.tdump > > > We are running wildfly in domain mode with the following configuration. > host A running domain controlller > host B running host controller with one app sever > host C running host controller with one app server > host D running host controller with one app server > When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:02:07 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 12 Nov 2014 03:02:07 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3628) removing session's entry(ies) from the cache error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro closed WFLY-3628. ------------------------------ Resolution: Out of Date [~olegsuknov] That issue is already fixed, see WFLY-3345 > removing session's entry(ies) from the cache error > -------------------------------------------------- > > Key: WFLY-3628 > URL: https://issues.jboss.org/browse/WFLY-3628 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.1.0.Final > Environment: Linux 2.6.32-431.3.1.el6.x86_64 (Red Hat 4.4.7-4) > 1 domain controller & 2 members in cluster > Reporter: oleg suknov > Assignee: Paul Ferraro > Fix For: 8.2.0.CR1 > > > There are no application data in session but there are some exceptions after wildfly attempted removing session's entry(ies) from the cache. > > 2014-06-30 15:57:15,166 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-60) ISPN000136: Execution error: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.NullPointerException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(org.infinispan.notifications.cachelistener.event.CacheEntryRemovedEvent)] on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager at 1bd3806d > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:211) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:229) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:192) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:230) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:96) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:213) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:92) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:91) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:275) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:80) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:132) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:321) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:402) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:216) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitRemoveCommand(OptimisticLockingInterceptor.java:135) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:255) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:196) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:206) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:156) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:166) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.CacheImpl.removeInternal(CacheImpl.java:407) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.CacheImpl.remove(CacheImpl.java:400) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.DecoratedCache.remove(DecoratedCache.java:406) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:281) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.jboss.as.clustering.infinispan.invoker.Remover$RemoveOperation.invoke(Remover.java:49) > at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34) > at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:82) > at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:117) > at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:55) > at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:74) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:157) > at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:353) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at org.jboss.weld.servlet.SessionHolder.requestInitialized(SessionHolder.java:47) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:168) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:153) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:216) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:239) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: java.lang.NullPointerException > at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51) > at org.wildfly.clustering.web.session.ImmutableHttpSessionAdapter.getAttributeNames(ImmutableHttpSessionAdapter.java:80) > at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getAttributeNames(AbstractSessionBeanStore.java:48) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at org.jboss.weld.context.beanstore.AttributeBeanStore.getPrefixedAttributeNames(AttributeBeanStore.java:198) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at org.jboss.weld.context.beanstore.AttributeBeanStore.attach(AttributeBeanStore.java:95) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at org.jboss.weld.context.AbstractBoundContext.activate(AbstractBoundContext.java:66) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at org.jboss.weld.servlet.WeldTerminalListener.sessionDestroyed(WeldTerminalListener.java:60) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23] > at io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(ApplicationListeners.java:264) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.clustering.web.undertow.session.UndertowSessionContext$1.sessionDestroyed(UndertowSessionContext.java:60) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:236) > at sun.reflect.GeneratedMethodAccessor67.invoke(Unknown Source) [:1.7.0_51] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_51] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_51] > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:207) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > ... 86 more > > 2014-06-30 15:57:15,181 ERROR [io.undertow.request] (default task-60) UT005023: Exception handling request to /hl/hl.jsp: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.NullPointerException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(org.infinispan.notifications.cachelistener.event.CacheEntryRemovedEvent)] on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager at 1bd3806d > at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:211) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22) [infinispan-core-6.0.2.Final.jar:6.0.2.Final] > > > > domain.xml: > ... > > ... > > > > > > > > > > ... > > > > > > > > > > > ... > > ... > > > > 300 > > > 20000 > > > > > > > > > > > false > > > false > > > > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:02:11 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 12 Nov 2014 03:02:11 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3536) Wildfly 8.1.0 Final keeps established connections forever In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas resolved WFLY-3536. ---------------------------------- Resolution: Done There are now three different options. - Idle timeout: A general idle timeout that applies to the connection at all times - no request timeout: The amount of time the connection can have no requests before the connection is closed - parse timeout: The amount of time that can be spent parsing a HTTP request > Wildfly 8.1.0 Final keeps established connections forever > --------------------------------------------------------- > > Key: WFLY-3536 > URL: https://issues.jboss.org/browse/WFLY-3536 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Ubuntu on Azure VM using Java-7 or Java-8. > Reporter: Renan Polo Montebelo > Assignee: Stuart Douglas > > Wildfly 8.1.0 Final seams to keep established TCP connections forever, instead of closing it after the time configured in the IO worker (default 60s). I only noticed this from clients using an Android app, so I guess that their Android App is not behaving well, but Wildfly should be able to handle such situation nicely. > If I activate "tcp-keep-alive" in /subsystem=undertow/server=default-server/http-listener=default the situation gets a lot better, although it is still not ideal. > After some 48 hours my Wildfly freezes because there are more than 4K tcp connections established. Seams that only WEB module freezes, because scheduled timers still work (I can see activity in my log). I've checked for TCP connections using netstat -n. > JBoss Web Server in 7.1.x confirmed not to have this issue. My deployed application is basically JPA / EJB / JAX-RS (Resteasy) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:02:12 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 12 Nov 2014 03:02:12 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3536) Wildfly 8.1.0 Final keeps established connections forever In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas updated WFLY-3536: --------------------------------- Fix Version/s: 8.2.0.CR1 9.0.0.Beta1 > Wildfly 8.1.0 Final keeps established connections forever > --------------------------------------------------------- > > Key: WFLY-3536 > URL: https://issues.jboss.org/browse/WFLY-3536 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: Ubuntu on Azure VM using Java-7 or Java-8. > Reporter: Renan Polo Montebelo > Assignee: Stuart Douglas > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > Wildfly 8.1.0 Final seams to keep established TCP connections forever, instead of closing it after the time configured in the IO worker (default 60s). I only noticed this from clients using an Android app, so I guess that their Android App is not behaving well, but Wildfly should be able to handle such situation nicely. > If I activate "tcp-keep-alive" in /subsystem=undertow/server=default-server/http-listener=default the situation gets a lot better, although it is still not ideal. > After some 48 hours my Wildfly freezes because there are more than 4K tcp connections established. Seams that only WEB module freezes, because scheduled timers still work (I can see activity in my log). I've checked for TCP connections using netstat -n. > JBoss Web Server in 7.1.x confirmed not to have this issue. My deployed application is basically JPA / EJB / JAX-RS (Resteasy) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:02:14 2014 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 12 Nov 2014 03:02:14 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-865) Release PicketBox 4.0.21.Final In-Reply-To: References: Message-ID: Stefan Guilhen created SECURITY-865: --------------------------------------- Summary: Release PicketBox 4.0.21.Final Key: SECURITY-865 URL: https://issues.jboss.org/browse/SECURITY-865 Project: PicketBox Issue Type: Component Upgrade Components: JBossSX, Security SPI Reporter: Stefan Guilhen Assignee: Stefan Guilhen -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:02:24 2014 From: issues at jboss.org (Daniel Bremiller (JIRA)) Date: Wed, 12 Nov 2014 03:02:24 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-646) remove package with duplicate Rule conditions infinite loop In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019122#comment-13019122 ] Daniel Bremiller commented on DROOLS-646: ----------------------------------------- The error also seems to occur if you insert the data and then try to add the rule. > remove package with duplicate Rule conditions infinite loop > ----------------------------------------------------------- > > Key: DROOLS-646 > URL: https://issues.jboss.org/browse/DROOLS-646 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 5.6.0.Final > Reporter: Daniel Bremiller > Assignee: Mark Proctor > Attachments: DroolsError.zip > > > Removal of a package containing two rules of the same condition that share a betanode causes an infinite loop. The Rules could be declared in seperate packages as well, when removing either would also reproduce the bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:02:24 2014 From: issues at jboss.org (Daniel Bremiller (JIRA)) Date: Wed, 12 Nov 2014 03:02:24 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-646) remove package with duplicate Rule conditions infinite loop In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019122#comment-13019122 ] Daniel Bremiller edited comment on DROOLS-646 at 11/11/14 11:03 PM: -------------------------------------------------------------------- The infinite loop also seems to occur if you insert the data and then try to add the rule. was (Author: daniel.bremiller): The error also seems to occur if you insert the data and then try to add the rule. > remove package with duplicate Rule conditions infinite loop > ----------------------------------------------------------- > > Key: DROOLS-646 > URL: https://issues.jboss.org/browse/DROOLS-646 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 5.6.0.Final > Reporter: Daniel Bremiller > Assignee: Mark Proctor > Attachments: DroolsError.zip > > > Removal of a package containing two rules of the same condition that share a betanode causes an infinite loop. The Rules could be declared in seperate packages as well, when removing either would also reproduce the bug. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 03:02:33 2014 From: issues at jboss.org (valsaraj viswanathan (JIRA)) Date: Wed, 12 Nov 2014 03:02:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1682) duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMESSAGING-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019138#comment-13019138 ] valsaraj viswanathan commented on JBMESSAGING-1682: --------------------------------------------------- Hi, We faced similar issue and our JBM version is 1.4.0. We have upgraded to JBM 1.4.1.Beta1. Is this version contains fix for this issue? Thanks! > duplicate key value violates unique constraint "jbm_msg_pkey" exceptions in a clustered > --------------------------------------------------------------------------------------- > > Key: JBMESSAGING-1682 > URL: https://issues.jboss.org/browse/JBMESSAGING-1682 > Project: JBoss Messaging > Issue Type: Bug > Components: JMS Clustering > Affects Versions: 1.4.0.SP3.CP02, 1.4.0.SP3_CP03, 1.4.0.SP3.CP04, 1.4.0.SP3.CP05, 1.4.0.SP3.CP06, 1.4.0.SP3.CP07, 1.4.0.SP3.CP08, 1.4.4.GA > Reporter: Masao Kato > Assignee: Yong Hao Gao > Priority: Blocker > Fix For: 1.4.0.SP3.CP09, 1.4.5.GA > > > NodeID(server peer id) of the cluster : in the adjoined identification number such as 0 and 1, 2 and 3. > When message ID is generated at the same time, the exception might be generated by the duplicate of ID. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 05:03:29 2014 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Wed, 12 Nov 2014 05:03:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-195) Outbound LDAP connection in domain mode test case In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek closed WFCORE-195. ------------------------------- > Outbound LDAP connection in domain mode test case > ------------------------------------------------- > > Key: WFCORE-195 > URL: https://issues.jboss.org/browse/WFCORE-195 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security, Test Suite > Affects Versions: 1.0.0.Alpha11 > Reporter: Ondrej Kotek > Assignee: Ondrej Kotek > Fix For: 1.0.0.Alpha11 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 05:44:30 2014 From: issues at jboss.org (Harikrishna Kallae (JIRA)) Date: Wed, 12 Nov 2014 05:44:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4073) Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" In-Reply-To: References: Message-ID: Harikrishna Kallae created WFLY-4073: ---------------------------------------- Summary: Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" Key: WFLY-4073 URL: https://issues.jboss.org/browse/WFLY-4073 Project: WildFly Issue Type: Bug Components: Web Services Affects Versions: 8.1.0.Final Environment: WildFly Reporter: Harikrishna Kallae Assignee: Alessio Soldano HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 05:46:29 2014 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Wed, 12 Nov 2014 05:46:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4073) Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated WFLY-4073: ---------------------------------- Component/s: Web (Undertow) (was: Web Services) > Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" > ------------------------------------------------------------------------------------------- > > Key: WFLY-4073 > URL: https://issues.jboss.org/browse/WFLY-4073 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: WildFly > Reporter: Harikrishna Kallae > Assignee: Alessio Soldano > > HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 05:46:30 2014 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Wed, 12 Nov 2014 05:46:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4073) Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated WFLY-4073: ---------------------------------- Assignee: Stuart Douglas (was: Alessio Soldano) > Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" > ------------------------------------------------------------------------------------------- > > Key: WFLY-4073 > URL: https://issues.jboss.org/browse/WFLY-4073 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: WildFly > Reporter: Harikrishna Kallae > Assignee: Stuart Douglas > > HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 06:07:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 12 Nov 2014 06:07:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4073) Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019291#comment-13019291 ] Darran Lofthouse commented on WFLY-4073: ---------------------------------------- Where are you sending this to? Port 8080 or the HTTP management port? > Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" > ------------------------------------------------------------------------------------------- > > Key: WFLY-4073 > URL: https://issues.jboss.org/browse/WFLY-4073 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: WildFly > Reporter: Harikrishna Kallae > Assignee: Stuart Douglas > > HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 06:24:29 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 12 Nov 2014 06:24:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4073) Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-4073: ------------------------------ Fix Version/s: 9.0.0.Beta1 > Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" > ------------------------------------------------------------------------------------------- > > Key: WFLY-4073 > URL: https://issues.jboss.org/browse/WFLY-4073 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: WildFly > Reporter: Harikrishna Kallae > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 06:26:29 2014 From: issues at jboss.org (Anonymous (JIRA)) Date: Wed, 12 Nov 2014 06:26:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-383) Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019297#comment-13019297 ] Anonymous commented on WFLY-383: -------------------------------- use this realisation shortlist to go on on hand. [url=http://restaurant-porat.com/?mMLNNo91u3nikeairmax.html]http://restaurant-porat.com/?mMLNNo91u3nikeairmax.html[/url] > Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase > ----------------------------------------------------------------- > > Key: WFLY-383 > URL: https://issues.jboss.org/browse/WFLY-383 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > I have marked this test as "@Ignore"d as I do not believe the capability that is being tested is actually valid. > I can not find any evidence that we ever intended for a role to role mapping within the jboss-web.xml instead we only intended a principal to role mapping. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 06:26:29 2014 From: issues at jboss.org (Anonymous (JIRA)) Date: Wed, 12 Nov 2014 06:26:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-383) Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019298#comment-13019298 ] Anonymous commented on WFLY-383: -------------------------------- but, Before you get the drift that I overly inclined to criticising by myself issue, There are women. [url=http://pattychanganker.com/?abr9Me6Dw2lvoutlet.asp]http://pattychanganker.com/?abr9Me6Dw2lvoutlet.asp[/url] > Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase > ----------------------------------------------------------------- > > Key: WFLY-383 > URL: https://issues.jboss.org/browse/WFLY-383 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > I have marked this test as "@Ignore"d as I do not believe the capability that is being tested is actually valid. > I can not find any evidence that we ever intended for a role to role mapping within the jboss-web.xml instead we only intended a principal to role mapping. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 06:41:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 12 Nov 2014 06:41:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-383) Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-383: ---------------------------------- Comment: was deleted (was: use this realisation shortlist to go on on hand. [url=http://restaurant-porat.com/?mMLNNo91u3nikeairmax.html]http://restaurant-porat.com/?mMLNNo91u3nikeairmax.html[/url]) > Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase > ----------------------------------------------------------------- > > Key: WFLY-383 > URL: https://issues.jboss.org/browse/WFLY-383 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > I have marked this test as "@Ignore"d as I do not believe the capability that is being tested is actually valid. > I can not find any evidence that we ever intended for a role to role mapping within the jboss-web.xml instead we only intended a principal to role mapping. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 06:41:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 12 Nov 2014 06:41:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-383) Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-383: ---------------------------------- Comment: was deleted (was: but, Before you get the drift that I overly inclined to criticising by myself issue, There are women. [url=http://pattychanganker.com/?abr9Me6Dw2lvoutlet.asp]http://pattychanganker.com/?abr9Me6Dw2lvoutlet.asp[/url]) > Re-Evaluate or Remove WebSecurityJBossWebXmlSecurityRolesTestCase > ----------------------------------------------------------------- > > Key: WFLY-383 > URL: https://issues.jboss.org/browse/WFLY-383 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > I have marked this test as "@Ignore"d as I do not believe the capability that is being tested is actually valid. > I can not find any evidence that we ever intended for a role to role mapping within the jboss-web.xml instead we only intended a principal to role mapping. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 06:55:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 06:55:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-195) Outbound LDAP connection in domain mode test case In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019326#comment-13019326 ] RH Bugzilla Integration commented on WFCORE-195: ------------------------------------------------ Ondrej Kotek changed the Status of [bug 1148400|https://bugzilla.redhat.com/show_bug.cgi?id=1148400] from ASSIGNED to POST > Outbound LDAP connection in domain mode test case > ------------------------------------------------- > > Key: WFCORE-195 > URL: https://issues.jboss.org/browse/WFCORE-195 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security, Test Suite > Affects Versions: 1.0.0.Alpha11 > Reporter: Ondrej Kotek > Assignee: Ondrej Kotek > Fix For: 1.0.0.Alpha11 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 07:26:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 07:26:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-158) Handlers should not be allowed to be removed if they're assigned to another handler or logger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019337#comment-13019337 ] RH Bugzilla Integration commented on WFCORE-158: ------------------------------------------------ Nikoleta Ziakova changed the Status of [bug 1007333|https://bugzilla.redhat.com/show_bug.cgi?id=1007333] from ON_QA to VERIFIED > Handlers should not be allowed to be removed if they're assigned to another handler or logger > --------------------------------------------------------------------------------------------- > > Key: WFCORE-158 > URL: https://issues.jboss.org/browse/WFCORE-158 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha12 > > > Handlers can currently be removed even if the handler is assigned to a logger or another handler. This allows an invalid {{logging.properties}} file to be written and will fail to start the server on the next boot. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 07:32:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 07:32:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-159) Handlers can be created with the same name as an existing handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019342#comment-13019342 ] RH Bugzilla Integration commented on WFCORE-159: ------------------------------------------------ Nikoleta Ziakova changed the Status of [bug 1151256|https://bugzilla.redhat.com/show_bug.cgi?id=1151256] from ON_QA to VERIFIED > Handlers can be created with the same name as an existing handler > ----------------------------------------------------------------- > > Key: WFCORE-159 > URL: https://issues.jboss.org/browse/WFCORE-159 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha12 > > > Handlers can be created with the same name as an existing handler. This was done to reconfigure differences in the logging subsystem XML and the logging.properties file. The problem is it will replace a handler during an {{ADD}} operation if the same name is used on another parent resource. > {code} > /subsystem=logging/async-handler=CONSOLE:add(queue-length=10,overflow-action=BLOCK) > {code} > This will replace the default console handler with the new one keeping the existing console-handler resource. The next boot also fails with no indication on the console. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 07:41:29 2014 From: issues at jboss.org (Harikrishna Kallae (JIRA)) Date: Wed, 12 Nov 2014 07:41:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4073) Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019347#comment-13019347 ] Harikrishna Kallae commented on WFLY-4073: ------------------------------------------ A server template is being used to make a HTTP request at port 8080 with "OPTIONS" http methods. > Wildfly 8.1.0 HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" > ------------------------------------------------------------------------------------------- > > Key: WFLY-4073 > URL: https://issues.jboss.org/browse/WFLY-4073 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: WildFly > Reporter: Harikrishna Kallae > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > HTTP Response Header throws 405 method not allowed with HTTP method "OPTIONS" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 08:06:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 08:06:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-242: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1162444, https://bugzilla.redhat.com/show_bug.cgi?id=1163173 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1162444) > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 08:32:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 08:32:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4060) Intermittent failures on SendMessage testcase when running with JTS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019379#comment-13019379 ] RH Bugzilla Integration commented on WFLY-4060: ----------------------------------------------- Ondrej Chaloupka changed the Status of [bug 1160761|https://bugzilla.redhat.com/show_bug.cgi?id=1160761] from ON_QA to VERIFIED > Intermittent failures on SendMessage testcase when running with JTS > ------------------------------------------------------------------- > > Key: WFLY-4060 > URL: https://issues.jboss.org/browse/WFLY-4060 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Ond?ej Chaloupka > Assignee: Ond?ej Chaloupka > > During testing EAP I was hitting intermittent failures on SendMessageTestscase which was caused by timing issues. > There is a bit more explanation of reasons at bz: https://bugzilla.redhat.com/show_bug.cgi?id=1160761 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 09:00:33 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 09:00:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2732) Injected EJB not available to MDB @PreDestroy methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019391#comment-13019391 ] RH Bugzilla Integration commented on WFLY-2732: ----------------------------------------------- baranowb changed the Status of [bug 1160575|https://bugzilla.redhat.com/show_bug.cgi?id=1160575] from NEW to ASSIGNED > Injected EJB not available to MDB @PreDestroy methods > ----------------------------------------------------- > > Key: WFLY-2732 > URL: https://issues.jboss.org/browse/WFLY-2732 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 8.0.0.Final > > Attachments: MDBLifeCycleJAR.zip > > > MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed. > This was fixed in an RFE for Session Beans but does not seem to work for MDB. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 09:43:30 2014 From: issues at jboss.org (Wojciech Grochowicz (JIRA)) Date: Wed, 12 Nov 2014 09:43:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-148) Postgres function to_char, lpad or rpad In-Reply-To: References: Message-ID: Wojciech Grochowicz created HIBERNATE-148: --------------------------------------------- Summary: Postgres function to_char, lpad or rpad Key: HIBERNATE-148 URL: https://issues.jboss.org/browse/HIBERNATE-148 Project: Hibernate Integration Issue Type: Bug Reporter: Wojciech Grochowicz Assignee: Steve Ebersole In Query org.hibernate.SharedSessionContract.getNamedQuery(String queryName) i create query with function to_char, lpad or rpad. For Example: @NamedQuery(name = "test", query = " from test where (to_char(YEAR, '9999')||lpad(substr(MONTH, 1),2,'01'))=:value") Query query = getSession().getNamedQuery("test"); query.setParameter("value", " 2014M2"); query.uniqueResult(); When i use Oracle in HSQL log show query: select (...) from test where (to_char(YEAR, '9999')||lpad(substr(MONTH, 2),2,'0'))=? So it is evrything ok. When i use Postgres in HSQL log show query: select (...) from test where (to_char(YEAR, '9999')||lpad(substr(MONTH, 2)||2||'0'))=? So in log i sow exception: org.hibernate.exception.SQLGrammarException: could not extract ResultSet at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:123) at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:91) at org.hibernate.loader.Loader.getResultSet(Loader.java:2065) at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1862) at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1838) at org.hibernate.loader.Loader.doQuery(Loader.java:909) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:354) at org.hibernate.loader.Loader.doList(Loader.java:2553) at org.hibernate.loader.Loader.doList(Loader.java:2539) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2369) at org.hibernate.loader.Loader.list(Loader.java:2364) at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:496) at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:387) at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:231) at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1264) at org.hibernate.internal.QueryImpl.list(QueryImpl.java:103) at org.hibernate.internal.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.java:966) at pl.sygnity.zsi.dao.uprawnienia.SlownikWartosciParametruCrudDao.getForParametr(SlownikWartosciParametruCrudDao.java:47) at pl.sygnity.zsi.business.ParametrSystemowyBusiness.getData(ParametrSystemowyBusiness.java:56) 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:483) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:190) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157) at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:98) at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:266) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:95) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) at com.sun.proxy.$Proxy489.getData(Unknown Source) at pl.sygnity.zsi.admin.action.podatkioplaty.ParametrSystemowyFilterAction.getDataSearch(ParametrSystemowyFilterAction.java:61) 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:483) at com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:450) at com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:289) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:252) at com.opensymphony.xwork2.interceptor.TimerInterceptor.invokeUnderTiming(TimerInterceptor.java:135) at com.opensymphony.xwork2.interceptor.TimerInterceptor.intercept(TimerInterceptor.java:122) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.LoggingInterceptor.intercept(LoggingInterceptor.java:67) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:256) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:189) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.spring.interceptor.ActionAutowiringInterceptor.intercept(ActionAutowiringInterceptor.java:120) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.I18nInterceptor.intercept(I18nInterceptor.java:139) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:167) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:265) at org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:68) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.interceptor.DeprecationInterceptor.intercept(DeprecationInterceptor.java:41) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:138) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:254) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:254) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.interceptor.MultiselectInterceptor.intercept(MultiselectInterceptor.java:73) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:91) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.PrepareInterceptor.doIntercept(PrepareInterceptor.java:171) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:98) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.interceptor.ServletConfigInterceptor.intercept(ServletConfigInterceptor.java:164) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:189) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:246) at org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:54) at org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:562) at org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:77) at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:99) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118) at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:103) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:154) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:45) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:199) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:110) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:50) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87) at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:344) at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:261) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:537) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1081) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) If i change NamedQuery to: @NamedQuery(name = "test", query = " from test where (to_char(YEAR, '9999')||rpad(substr(MONTH, 1),2,'01'))=:value") It is the same exception in log. But when i use another function with parameters, for example: @NamedQuery(name = "test", query = " from test where (to_char(YEAR, '9999')||substr(substr(MONTH, 1),2,'01'))=:value") So, it is everything ok. And when i use only lpad or rpad function, for example: @NamedQuery(name = "test", query = " from test where lpad('hi', 5, 'xy')>=?=:value") So, it is everything ok. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 10:00:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 10:00:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019432#comment-13019432 ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Marek Kopecky changed the Status of [bug 1149618|https://bugzilla.redhat.com/show_bug.cgi?id=1149618] from ON_QA to VERIFIED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 11:21:29 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Wed, 12 Nov 2014 11:21:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-244) Upgrade jboss-logging from 3.1.4.GA to 3.2.0.Final In-Reply-To: References: Message-ID: James Perkins created WFCORE-244: ------------------------------------ Summary: Upgrade jboss-logging from 3.1.4.GA to 3.2.0.Final Key: WFCORE-244 URL: https://issues.jboss.org/browse/WFCORE-244 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: James Perkins Assignee: James Perkins Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 11:49:29 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 12 Nov 2014 11:49:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4074) pop3 mail session throws a NoSuchProviderException In-Reply-To: References: Message-ID: Tomaz Cerar created WFLY-4074: --------------------------------- Summary: pop3 mail session throws a NoSuchProviderException Key: WFLY-4074 URL: https://issues.jboss.org/browse/WFLY-4074 Project: WildFly Issue Type: Bug Components: Mail Affects Versions: 8.1.0.Final Reporter: Tomaz Cerar Assignee: Tomaz Cerar Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 11:49:29 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 12 Nov 2014 11:49:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4074) pop3 mail session throws a NoSuchProviderException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-4074: ------------------------------ Description: When configuring a pop3 server in standalone.xml as, the following exception is thrown when reading the mailbox: Caused by: javax.mail.NoSuchProviderException: Invalid protocol: null at javax.mail.Session.getProvider(Session.java:440) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] at javax.mail.Session.getStore(Session.java:539) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > pop3 mail session throws a NoSuchProviderException > -------------------------------------------------- > > Key: WFLY-4074 > URL: https://issues.jboss.org/browse/WFLY-4074 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > When configuring a pop3 server in standalone.xml as, the following exception is thrown when reading the mailbox: > Caused by: javax.mail.NoSuchProviderException: Invalid protocol: null > at javax.mail.Session.getProvider(Session.java:440) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > at javax.mail.Session.getStore(Session.java:539) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 11:50:29 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 12 Nov 2014 11:50:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4074) pop3 mail session throws a NoSuchProviderException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-4074: ------------------------------ Steps to Reproduce: 1. add a pop3 server in the mail section 2. try to read the mailbox > pop3 mail session throws a NoSuchProviderException > -------------------------------------------------- > > Key: WFLY-4074 > URL: https://issues.jboss.org/browse/WFLY-4074 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > When configuring a pop3 server in standalone.xml as, the following exception is thrown when reading the mailbox: > Caused by: javax.mail.NoSuchProviderException: Invalid protocol: null > at javax.mail.Session.getProvider(Session.java:440) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > at javax.mail.Session.getStore(Session.java:539) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 11:50:30 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 12 Nov 2014 11:50:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4074) pop3 mail session throws a NoSuchProviderException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-4074: ------------------------------ Steps to Reproduce: 1. add a pop3 server in the mail section {code:xml} {code} 2. try to read the mailbox was: 1. add a pop3 server in the mail section 2. try to read the mailbox > pop3 mail session throws a NoSuchProviderException > -------------------------------------------------- > > Key: WFLY-4074 > URL: https://issues.jboss.org/browse/WFLY-4074 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > When configuring a pop3 server in standalone.xml as, the following exception is thrown when reading the mailbox: > Caused by: javax.mail.NoSuchProviderException: Invalid protocol: null > at javax.mail.Session.getProvider(Session.java:440) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > at javax.mail.Session.getStore(Session.java:539) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 11:51:29 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 12 Nov 2014 11:51:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4074) pop3 mail session throws a NoSuchProviderException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-4074: ------------------------------ Description: When configuring a pop3 server in standalone.xml as, the following exception is thrown when reading the mailbox: {noformat} Caused by: javax.mail.NoSuchProviderException: Invalid protocol: null at javax.mail.Session.getProvider(Session.java:440) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] at javax.mail.Session.getStore(Session.java:539) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] {noformat} was: When configuring a pop3 server in standalone.xml as, the following exception is thrown when reading the mailbox: Caused by: javax.mail.NoSuchProviderException: Invalid protocol: null at javax.mail.Session.getProvider(Session.java:440) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] at javax.mail.Session.getStore(Session.java:539) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > pop3 mail session throws a NoSuchProviderException > -------------------------------------------------- > > Key: WFLY-4074 > URL: https://issues.jboss.org/browse/WFLY-4074 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > When configuring a pop3 server in standalone.xml as, the following exception is thrown when reading the mailbox: > {noformat} > Caused by: javax.mail.NoSuchProviderException: Invalid protocol: null > at javax.mail.Session.getProvider(Session.java:440) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > at javax.mail.Session.getStore(Session.java:539) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 11:57:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 12 Nov 2014 11:57:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-227: ------------------------------------ Component/s: Domain Management > RejectedExecutionException when closing ModelControllerClient client > -------------------------------------------------------------------- > > Key: WFCORE-227 > URL: https://issues.jboss.org/browse/WFCORE-227 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Alessio Soldano > Fix For: 1.0.0.Alpha13 > > > After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite: > {noformat} > Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3 at 5651c0c2 rejected from org.xnio.XnioWorker$TaskPool at 11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) > at org.xnio.XnioWorker.execute(XnioWorker.java:741) > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363) > at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method. > The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 11:59:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 11:59:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4074) pop3 mail session throws a NoSuchProviderException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4074: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1163150 > pop3 mail session throws a NoSuchProviderException > -------------------------------------------------- > > Key: WFLY-4074 > URL: https://issues.jboss.org/browse/WFLY-4074 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > When configuring a pop3 server in standalone.xml as, the following exception is thrown when reading the mailbox: > {noformat} > Caused by: javax.mail.NoSuchProviderException: Invalid protocol: null > at javax.mail.Session.getProvider(Session.java:440) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > at javax.mail.Session.getStore(Session.java:539) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 12:38:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 12 Nov 2014 12:38:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-227) RejectedExecutionException when closing ModelControllerClient client In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-227: ------------------------------------ Fix Version/s: (was: 1.0.0.Alpha13) Assignee: David Lloyd Component/s: Remoting David, per chat discussion it looks like you are looking at this in terms of a remoting change. If there's anything we must do to mitigate this, let me know. I find it a bit odd that RemotingModelControllerClient.close() is calling channelAssociation.shutdownNow *after* closing the channel and endpoint, and if were done first perhaps the result could be that ManagementChannelReceiver stops registering itself after each message. But there's probably still a race there anyway and I don't want to start mucking with this stuff unless I need to. > RejectedExecutionException when closing ModelControllerClient client > -------------------------------------------------------------------- > > Key: WFCORE-227 > URL: https://issues.jboss.org/browse/WFCORE-227 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting > Affects Versions: 1.0.0.Alpha11 > Reporter: Alessio Soldano > Assignee: David Lloyd > > After wildfly-core 1.0.0.Alpha11 has been included in WFLY master, I'm seeing hundreds of the following exceptions in the logs when running the JBossWS-CXF testsuite: > {noformat} > Exception in thread "Remoting "management-client" task-4" java.util.concurrent.RejectedExecutionException: Task org.jboss.remoting3.remote.RemoteConnectionChannel$3 at 5651c0c2 rejected from org.xnio.XnioWorker$TaskPool at 11462cd4[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 4] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2048) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:821) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1372) > at org.xnio.XnioWorker.execute(XnioWorker.java:741) > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:363) > at org.jboss.as.protocol.mgmt.ManagementChannelReceiver.handleMessage(ManagementChannelReceiver.java:107) > at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:451) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:745) > {noformat} > The exception is logged just after the org.jboss.as.webservices.deployer.RemoteDeployer calls the RemotingModelControllerClient#close method. > The issue seems to be related to some kind of race condition, as trying to reproduce it with an attached debugger is not possible. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 12:57:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 12:57:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4074) pop3 mail session throws a NoSuchProviderException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019506#comment-13019506 ] RH Bugzilla Integration commented on WFLY-4074: ----------------------------------------------- Tomaz Cerar changed the Status of [bug 1163150|https://bugzilla.redhat.com/show_bug.cgi?id=1163150] from NEW to POST > pop3 mail session throws a NoSuchProviderException > -------------------------------------------------- > > Key: WFLY-4074 > URL: https://issues.jboss.org/browse/WFLY-4074 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > When configuring a pop3 server in standalone.xml as, the following exception is thrown when reading the mailbox: > {noformat} > Caused by: javax.mail.NoSuchProviderException: Invalid protocol: null > at javax.mail.Session.getProvider(Session.java:440) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > at javax.mail.Session.getStore(Session.java:539) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 12:59:29 2014 From: issues at jboss.org (Patson Luk (JIRA)) Date: Wed, 12 Nov 2014 12:59:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4070) Dispatcher modifies result of getRequestURI of the original request object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019507#comment-13019507 ] Patson Luk commented on WFLY-4070: ---------------------------------- Thanks for the quick reply! Yes I have tested on both Tomcat 7 and JBoss as 7 - both retain the the originating URI on the original Servlet Request object after dispatcher forwards. This can be easily reproduce by deploying the war attachment to those app servers > Dispatcher modifies result of getRequestURI of the original request object > -------------------------------------------------------------------------- > > Key: WFLY-4070 > URL: https://issues.jboss.org/browse/WFLY-4070 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Patson Luk > Assignee: Stuart Douglas > Attachments: test-wildfly.war, test-wildfly.zip > > > This is actually similar to https://issues.jboss.org/browse/WFLY-2388, which was fixed in 8.0.0.CR1 > However, it seems like with RequestDispatcher forward, the ORIGINAL ServletRequest object's getRequestURI returns the forwarded URI as the result, which is not correct. It is expected that the original ServletRequest object should retain its originating requested URI throughout the processing. > This seems to affect all the versions of Wildfly (tested on 8.1 and 9.0 alpha) > Take note that this has also been tested on JBoss AS 7 and tomcat 7, both have correctly retained the originating URI as expected even after dispatcher forwards -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 13:07:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 13:07:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-195) Outbound LDAP connection in domain mode test case In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019510#comment-13019510 ] RH Bugzilla Integration commented on WFCORE-195: ------------------------------------------------ Kabir Khan changed the Status of [bug 1148400|https://bugzilla.redhat.com/show_bug.cgi?id=1148400] from POST to MODIFIED > Outbound LDAP connection in domain mode test case > ------------------------------------------------- > > Key: WFCORE-195 > URL: https://issues.jboss.org/browse/WFCORE-195 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security, Test Suite > Affects Versions: 1.0.0.Alpha11 > Reporter: Ondrej Kotek > Assignee: Ondrej Kotek > Fix For: 1.0.0.Alpha11 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 13:18:29 2014 From: issues at jboss.org (Patson Luk (JIRA)) Date: Wed, 12 Nov 2014 13:18:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4070) Dispatcher modifies result of getRequestURI of the original request object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019507#comment-13019507 ] Patson Luk edited comment on WFLY-4070 at 11/12/14 1:18 PM: ------------------------------------------------------------ Thanks for the quick reply! Yes I have tested on both Tomcat 7 and JBoss as 7 - both retain the the originating URI on the original Servlet Request object after dispatcher forwards. This can be easily reproduce by deploying the war attachment to those app servers Access the root of the application the below will be triggered: 1. TestFilter gets executed as it has @WebFilter(urlPatterns = "/*") it calls next filter in chain 2. No other filter, so TestDispatcher is executed as it has @WebServlet("/"). The servlet get requestDispatcher on index.jsp and then forward the request 3. Goes back to TestFilter, which it output the request.getRequestURI to the System.out. Take note that the request object is the original request object passed into the filter's doFilter method On Tomcat 7 and JBoss as-7, both display: Finished processing request with requested URI as : /test-wildfly/ On Wildfly: Finished processing request with requested URI as : /test-wildfly/index.jsp was (Author: pluk): Thanks for the quick reply! Yes I have tested on both Tomcat 7 and JBoss as 7 - both retain the the originating URI on the original Servlet Request object after dispatcher forwards. This can be easily reproduce by deploying the war attachment to those app servers > Dispatcher modifies result of getRequestURI of the original request object > -------------------------------------------------------------------------- > > Key: WFLY-4070 > URL: https://issues.jboss.org/browse/WFLY-4070 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Patson Luk > Assignee: Stuart Douglas > Attachments: test-wildfly.war, test-wildfly.zip > > > This is actually similar to https://issues.jboss.org/browse/WFLY-2388, which was fixed in 8.0.0.CR1 > However, it seems like with RequestDispatcher forward, the ORIGINAL ServletRequest object's getRequestURI returns the forwarded URI as the result, which is not correct. It is expected that the original ServletRequest object should retain its originating requested URI throughout the processing. > This seems to affect all the versions of Wildfly (tested on 8.1 and 9.0 alpha) > Take note that this has also been tested on JBoss AS 7 and tomcat 7, both have correctly retained the originating URI as expected even after dispatcher forwards -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 13:21:29 2014 From: issues at jboss.org (Patson Luk (JIRA)) Date: Wed, 12 Nov 2014 13:21:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4070) Dispatcher modifies result of getRequestURI of the original request object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019507#comment-13019507 ] Patson Luk edited comment on WFLY-4070 at 11/12/14 1:21 PM: ------------------------------------------------------------ Thanks for the quick reply! Yes I have tested on both Tomcat 7 and JBoss as 7 - both retain the the originating URI on the original Servlet Request object after dispatcher forwards. This can be easily reproduce by deploying the war attachment to those app servers Access the root of the application the below will be triggered: 1. TestFilter gets executed as it has @WebFilter(urlPatterns = "/*"), it calls next filter in chain 2. No other filters, so TestDispatcher is executed as it has @WebServlet("/"). The servlet obtains requestDispatcher on "index.jsp" and then forwards the request with it 3. index.jsp is a simple page with static text 4. Goes back to TestFilter, which outputs the request.getRequestURI to System.out. Take note that the request object is the original Servlet Request object passed into the filter's doFilter method On Tomcat 7 and JBoss as-7, both display: Finished processing request with requested URI as : /test-wildfly/ On Wildfly: Finished processing request with requested URI as : /test-wildfly/index.jsp was (Author: pluk): Thanks for the quick reply! Yes I have tested on both Tomcat 7 and JBoss as 7 - both retain the the originating URI on the original Servlet Request object after dispatcher forwards. This can be easily reproduce by deploying the war attachment to those app servers Access the root of the application the below will be triggered: 1. TestFilter gets executed as it has @WebFilter(urlPatterns = "/*") it calls next filter in chain 2. No other filter, so TestDispatcher is executed as it has @WebServlet("/"). The servlet get requestDispatcher on index.jsp and then forward the request 3. Goes back to TestFilter, which it output the request.getRequestURI to the System.out. Take note that the request object is the original request object passed into the filter's doFilter method On Tomcat 7 and JBoss as-7, both display: Finished processing request with requested URI as : /test-wildfly/ On Wildfly: Finished processing request with requested URI as : /test-wildfly/index.jsp > Dispatcher modifies result of getRequestURI of the original request object > -------------------------------------------------------------------------- > > Key: WFLY-4070 > URL: https://issues.jboss.org/browse/WFLY-4070 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Patson Luk > Assignee: Stuart Douglas > Attachments: test-wildfly.war, test-wildfly.zip > > > This is actually similar to https://issues.jboss.org/browse/WFLY-2388, which was fixed in 8.0.0.CR1 > However, it seems like with RequestDispatcher forward, the ORIGINAL ServletRequest object's getRequestURI returns the forwarded URI as the result, which is not correct. It is expected that the original ServletRequest object should retain its originating requested URI throughout the processing. > This seems to affect all the versions of Wildfly (tested on 8.1 and 9.0 alpha) > Take note that this has also been tested on JBoss AS 7 and tomcat 7, both have correctly retained the originating URI as expected even after dispatcher forwards -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 14:02:29 2014 From: issues at jboss.org (Roger Lefebvre (JIRA)) Date: Wed, 12 Nov 2014 14:02:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-645) Accumulate returned fact causing NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019520#comment-13019520 ] Roger Lefebvre commented on DROOLS-645: --------------------------------------- Concerning the bug in the accumulator class, you are correct. The version I had working with the list was cast as you have shown. Based on the rule you have defined, it should have worked. That said, I have yet to test it on my platform. I will report back once that is done. Regardless of the outcome, I will use the approach you suggested to eliminate the accumulator. In writing the rule, I kept saying to myself there had to be a simpler way. Still a bit green with formulating rules. It would be nice to have a drools page with practical rule suggestions that an audience can add to. > Accumulate returned fact causing NPE > ------------------------------------ > > Key: DROOLS-645 > URL: https://issues.jboss.org/browse/DROOLS-645 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta2 > Environment: Mac OSX (maverick) > Reporter: Roger Lefebvre > Assignee: Mario Fusco > Attachments: RetryOldestCallTimeAccumulateFunction.java, RetryOldestCallTimeAccumulateFunction.java > > > The issue is discussed in https://groups.google.com/forum/?hl=en-GB#!topic/drools-usage/aZU5mXSgHMI. > Here is the gist of it.... > I changed the accumulator to the following and it worked: > accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), $message:oldestRetry( $sm )) > The previous approach was this: > $message:StatusMessage() from accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), oldestRetry( $sm )) > which I thought was the correct or acceptable syntax option. Is there something I have overlooked in the second one ("from"??). It does give me a StatusMessage object but it lacks the underlying properties to allow the subsequent modify to work. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 15:11:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 15:11:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2210) fix message endpoint isDeliveryTransacted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019536#comment-13019536 ] RH Bugzilla Integration commented on WFLY-2210: ----------------------------------------------- Dominik Pospisil changed the Status of [bug 1161078|https://bugzilla.redhat.com/show_bug.cgi?id=1161078] from POST to MODIFIED > fix message endpoint isDeliveryTransacted > ----------------------------------------- > > Key: WFLY-2210 > URL: https://issues.jboss.org/browse/WFLY-2210 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Alpha4 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 8.0.0.CR1 > > > The org.jboss.as.ejb3.inflow.MessageEndpointService#isDeliveryTransacted method is checking the transaction attribute of the method using the MethodIntf.BEAN while it should use the MethodIntf.MESSAGE_ENDPOINT type. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 15:12:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 15:12:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3942) Race condition with clean shutdown and mod_cluster session draining In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019537#comment-13019537 ] RH Bugzilla Integration commented on WFLY-3942: ----------------------------------------------- Dominik Pospisil changed the Status of [bug 1161079|https://bugzilla.redhat.com/show_bug.cgi?id=1161079] from POST to MODIFIED > Race condition with clean shutdown and mod_cluster session draining > ------------------------------------------------------------------- > > Key: WFLY-3942 > URL: https://issues.jboss.org/browse/WFLY-3942 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final, 8.1.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > Probably same issue exists in WF as well, I will revalidate the logic for race conditions. > https://issues.jboss.org/browse/MODCLUSTER-399 > https://bugzilla.redhat.com/show_bug.cgi?id=1083563 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 15:15:32 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 12 Nov 2014 15:15:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019541#comment-13019541 ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Dominik Pospisil changed the Status of [bug 1149621|https://bugzilla.redhat.com/show_bug.cgi?id=1149621] from POST to MODIFIED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 22:35:31 2014 From: issues at jboss.org (Michael Davis (JIRA)) Date: Wed, 12 Nov 2014 22:35:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3221) flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019592#comment-13019592 ] Michael Davis commented on WFLY-3221: ------------------------------------- Pavel Kovalenko, thanks so much for submitting that code. It totally saved my hide tonight. My use case is: An administrator wants to change someone else's password so that they can either log in or be locked out. So I didn't want to flush the cache when the current user logged out but rather when we changed someone's password. It was trivial, after looking at you code. Cheers, Michael Davis Ottawa > flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials > ------------------------------------------------------------------------------------- > > Key: WFLY-3221 > URL: https://issues.jboss.org/browse/WFLY-3221 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.0.0.Final > Reporter: Jorge Marmolejo > Assignee: Stuart Douglas > Priority: Critical > Fix For: 9.0.0.Beta1 > > > The attribute flushOnSessionInvalidation does not flush the user credentials when the session is invalidated or when it times out. If the password or roles change for the user, the only way to get the new changes is by restarting the server. > I tried removing "cache-type=default" from the standalone-full.xml and it works, but for every action made on the site, the login method in the authentication module is called. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 12 22:36:31 2014 From: issues at jboss.org (Michael Davis (JIRA)) Date: Wed, 12 Nov 2014 22:36:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3221) flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019592#comment-13019592 ] Michael Davis edited comment on WFLY-3221 at 11/12/14 10:36 PM: ---------------------------------------------------------------- Pavel Kovalenko, thanks so much for submitting that code. It totally saved my hide tonight. My use case is: An administrator wants to change someone else's password so that they can either log in or be locked out. So I didn't want to flush the cache when the current user logged out but rather when we changed someone's password. It was trivial, after looking at your code. Cheers, Michael Davis Ottawa was (Author: damaru): Pavel Kovalenko, thanks so much for submitting that code. It totally saved my hide tonight. My use case is: An administrator wants to change someone else's password so that they can either log in or be locked out. So I didn't want to flush the cache when the current user logged out but rather when we changed someone's password. It was trivial, after looking at you code. Cheers, Michael Davis Ottawa > flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials > ------------------------------------------------------------------------------------- > > Key: WFLY-3221 > URL: https://issues.jboss.org/browse/WFLY-3221 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.0.0.Final > Reporter: Jorge Marmolejo > Assignee: Stuart Douglas > Priority: Critical > Fix For: 9.0.0.Beta1 > > > The attribute flushOnSessionInvalidation does not flush the user credentials when the session is invalidated or when it times out. If the password or roles change for the user, the only way to get the new changes is by restarting the server. > I tried removing "cache-type=default" from the standalone-full.xml and it works, but for every action made on the site, the login method in the authentication module is called. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 00:02:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 00:02:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2732) Injected EJB not available to MDB @PreDestroy methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019594#comment-13019594 ] RH Bugzilla Integration commented on WFLY-2732: ----------------------------------------------- baranowb changed the Status of [bug 1160575|https://bugzilla.redhat.com/show_bug.cgi?id=1160575] from ASSIGNED to POST > Injected EJB not available to MDB @PreDestroy methods > ----------------------------------------------------- > > Key: WFLY-2732 > URL: https://issues.jboss.org/browse/WFLY-2732 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 8.0.0.Final > > Attachments: MDBLifeCycleJAR.zip > > > MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed. > This was fixed in an RFE for Session Beans but does not seem to work for MDB. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 01:22:30 2014 From: issues at jboss.org (Yehudit Glass (JIRA)) Date: Thu, 13 Nov 2014 01:22:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-648) Bottleneck during the creation of the object type configurations In-Reply-To: References: Message-ID: Yehudit Glass created DROOLS-648: ------------------------------------ Summary: Bottleneck during the creation of the object type configurations Key: DROOLS-648 URL: https://issues.jboss.org/browse/DROOLS-648 Project: Drools Issue Type: Bug Affects Versions: 6.2.0.CR1 Reporter: Yehudit Glass Assignee: Mark Proctor Priority: Critical There is indeed a bottleneck during the creation of the object type configurations. On insert facts to state full session it cause drools to go to ProjectClassLoader.loadClasss code which is synchronize and block threads which led to bad performance (when working multi threading). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 01:23:29 2014 From: issues at jboss.org (Yehudit Glass (JIRA)) Date: Thu, 13 Nov 2014 01:23:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-648) Bottleneck during the creation of the object type configurations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019599#comment-13019599 ] Yehudit Glass commented on DROOLS-648: -------------------------------------- https://groups.google.com/forum/#!topic/drools-development/xb1e6P3nVGM > Bottleneck during the creation of the object type configurations > ---------------------------------------------------------------- > > Key: DROOLS-648 > URL: https://issues.jboss.org/browse/DROOLS-648 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.CR1 > Reporter: Yehudit Glass > Assignee: Mark Proctor > Priority: Critical > > There is indeed a bottleneck during the creation of the object type configurations. > On insert facts to state full session it cause drools to go to ProjectClassLoader.loadClasss code which is synchronize and block threads which led to bad performance (when working multi threading). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 02:41:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 02:41:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019605#comment-13019605 ] RH Bugzilla Integration commented on WFCORE-242: ------------------------------------------------ baranowb changed the Status of [bug 1163173|https://bugzilla.redhat.com/show_bug.cgi?id=1163173] from NEW to ASSIGNED > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 02:53:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 02:53:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019608#comment-13019608 ] RH Bugzilla Integration commented on WFCORE-213: ------------------------------------------------ baranowb changed the Status of [bug 1163634|https://bugzilla.redhat.com/show_bug.cgi?id=1163634] from NEW to ASSIGNED > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha13, 1.0.0.Beta1 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 03:20:46 2014 From: issues at jboss.org (Jay Kumar SenSharma (JIRA)) Date: Thu, 13 Nov 2014 03:20:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) If the WildFly installation directory path contains space then JaxrsSpringProcessor causes NullPointerException In-Reply-To: References: Message-ID: Jay Kumar SenSharma created WFLY-4075: ----------------------------------------- Summary: If the WildFly installation directory path contains space then JaxrsSpringProcessor causes NullPointerException Key: WFLY-4075 URL: https://issues.jboss.org/browse/WFLY-4075 Project: WildFly Issue Type: Bug Components: REST, VFS Affects Versions: 9.0.0.Alpha1 Reporter: Jay Kumar SenSharma Assignee: Stuart Douglas - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: {code} 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] ... 5 more Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) ... 6 more Caused by: java.lang.NullPointerException at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) ... 7 more 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException Caused by: java.lang.NullPointerException"}} {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 03:21:29 2014 From: issues at jboss.org (Jay Kumar SenSharma (JIRA)) Date: Thu, 13 Nov 2014 03:21:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) If the WildFly installation directory path contains space then JaxrsSpringProcessor causes NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kumar SenSharma updated WFLY-4075: -------------------------------------- Forum Reference: https://developer.jboss.org/thread/250088 > If the WildFly installation directory path contains space then JaxrsSpringProcessor causes NullPointerException > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4075 > URL: https://issues.jboss.org/browse/WFLY-4075 > Project: WildFly > Issue Type: Bug > Components: REST, VFS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Stuart Douglas > > - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: > {code} > 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld > 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) > ... 6 more > Caused by: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) > ... 7 more > 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 03:24:29 2014 From: issues at jboss.org (Jay Kumar SenSharma (JIRA)) Date: Thu, 13 Nov 2014 03:24:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) If the WildFly installation directory path contains space then JaxrsSpringProcessor causes NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kumar SenSharma updated WFLY-4075: -------------------------------------- Forum Reference: https://developer.jboss.org/thread/250088, https://developer.jboss.org/thread/249900 (was: https://developer.jboss.org/thread/250088) > If the WildFly installation directory path contains space then JaxrsSpringProcessor causes NullPointerException > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4075 > URL: https://issues.jboss.org/browse/WFLY-4075 > Project: WildFly > Issue Type: Bug > Components: REST, VFS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Stuart Douglas > > - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: > {code} > 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld > 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) > ... 6 more > Caused by: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) > ... 7 more > 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 03:33:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 03:33:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) If the WildFly installation directory path contains space then JaxrsSpringProcessor causes NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4075: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1163646 > If the WildFly installation directory path contains space then JaxrsSpringProcessor causes NullPointerException > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4075 > URL: https://issues.jboss.org/browse/WFLY-4075 > Project: WildFly > Issue Type: Bug > Components: REST, VFS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Stuart Douglas > > - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: > {code} > 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld > 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) > ... 6 more > Caused by: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) > ... 7 more > 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 04:09:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 04:09:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3849) logging improvement to WFLYSEC0015 (vault security exception) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019616#comment-13019616 ] RH Bugzilla Integration commented on WFLY-3849: ----------------------------------------------- Peter Skopek changed the Status of [bug 1073603|https://bugzilla.redhat.com/show_bug.cgi?id=1073603] from ASSIGNED to POST > logging improvement to WFLYSEC0015 (vault security exception) > ------------------------------------------------------------- > > Key: WFLY-3849 > URL: https://issues.jboss.org/browse/WFLY-3849 > Project: WildFly > Issue Type: Enhancement > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Ivo Studensky > Assignee: Ivo Studensky > > Description of problem (taken from bz1073603): > Include which vault property resolution has failed in following error message: > java.lang.SecurityException: JBAS013311: Security Exception > at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:104) > For example, this would be helpful: > java.lang.SecurityException: JBAS013311: Security Exception (Error resolving vault property: ${VAULT:example:example:1} > How reproducible: > Using a vault property that doesn't exist will give this error message. > Steps to Reproduce: > 1. setup vault as normal > 2. use a vault property that doesn't exist > Actual results: > Get: > java.lang.SecurityException: JBAS013311: Security Exception > at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:104) > Expected results: > log message that show the property that failed -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 05:00:29 2014 From: issues at jboss.org (Jim Ma (JIRA)) Date: Thu, 13 Nov 2014 05:00:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule In-Reply-To: References: Message-ID: Jim Ma created SECURITY-866: ------------------------------- Summary: Add jboss module option to ServerLoginModule Key: SECURITY-866 URL: https://issues.jboss.org/browse/SECURITY-866 Project: PicketBox Issue Type: Task Components: PicketBox Reporter: Jim Ma If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 05:07:29 2014 From: issues at jboss.org (Jim Ma (JIRA)) Date: Thu, 13 Nov 2014 05:07:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019635#comment-13019635 ] Jim Ma commented on SECURITY-866: --------------------------------- PR for this task: https://github.com/picketbox/picketbox/pull/22 > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 05:09:30 2014 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Thu, 13 Nov 2014 05:09:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4018) CVE-2014-3623 Web Services flaw In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano resolved WFLY-4018. ----------------------------------- Resolution: Done Resolved by the upgrade in WFLY-4019 > CVE-2014-3623 Web Services flaw > ------------------------------- > > Key: WFLY-4018 > URL: https://issues.jboss.org/browse/WFLY-4018 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Reporter: Arun Neelicattu > Assignee: Alessio Soldano > Labels: CVE-2014-3623, component:cxf, component:wss4j > Fix For: 9.0.0.Beta1 > > > WildFly tracking bug for multiple vulnerabilities affecting the Web Services component. > See [CVE-2014-3623|https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-3623] for more information regarding the flaw. > Upgrading cxf to 2.7.13 and wss4j to 1.6.17 will resolve this. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 05:17:29 2014 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Thu, 13 Nov 2014 05:17:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3253) CXF should not be installing BouncyCastle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano resolved WFLY-3253. ----------------------------------- Resolution: Done Marking as solved; WFLY-4019 pulls Apache CXF 3.0.2 and is not installing BouncyCastle anymore (it's installing a ThreadLocalSecurityProvider which the ws stack sets and unsets a BC provider instance just before and after actual need) > CXF should not be installing BouncyCastle > ----------------------------------------- > > Key: WFLY-3253 > URL: https://issues.jboss.org/browse/WFLY-3253 > Project: WildFly > Issue Type: Bug > Components: Web Services > Reporter: David Lloyd > Assignee: Alessio Soldano > Priority: Critical > Fix For: 9.0.0.Beta1 > > > CXF installs a BouncyCastle provider globally into the security providers list. This is causes performance and other problems when this provider gets chosen for whatever reason to be the system crypto provider for e.g. TLS. > The list of globally installed security providers should be a user concern only. If CXF requires a specific provider for a specific purpose, it should be selecting that provider when constructing the crytpo API object, though generally this is to be discouraged. > Ultimately we want to introduce a configuration in the app server that allows the list of security providers to be specified in some way, without interference from any frameworks that we happen to have installed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 05:18:30 2014 From: issues at jboss.org (Mauro Molinari (JIRA)) Date: Thu, 13 Nov 2014 05:18:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-111) LoggerProvider configured with new ServiceLoader crash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBLOGGING-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019648#comment-13019648 ] Mauro Molinari commented on JBLOGGING-111: ------------------------------------------ I also encountered this problem. I want to force the use of SLF4J, but system properties for this is a really bad idea. The service locator technique would be OK (although not optimal), but as of JBoss Logging 3.2.0 this doesn't work for the exact reason written in the original report. I really can't understand the concerns about making the default {{LoggerProvider}} implementations public... > LoggerProvider configured with new ServiceLoader crash > ------------------------------------------------------ > > Key: JBLOGGING-111 > URL: https://issues.jboss.org/browse/JBLOGGING-111 > Project: JBoss Logging > Issue Type: Bug > Affects Versions: 3.2.0.Beta1 > Environment: Weblogic 10.3.2.0 > Configured in ejb jar, deployed by an ear file > Reporter: Frederic Allard > Assignee: James Perkins > > There is a new feature in the beta which uses the ServiceLoader to specify a LoggerProvider to be used by JBoss Logging. > org.jboss.logging.LoggerProviders snippet : > {code} > // Next try for a service provider > try { > final ServiceLoader loader = ServiceLoader.load(LoggerProvider.class, cl); > if (loader.iterator().hasNext()) { > return loader.iterator().next(); > } > } catch (Throwable ignore) { > // TODO consider printing the stack trace as it should only happen once > } > {code} > When you try to configure a provider (ex. org.jboss.logging.Slf4jLoggerProvider), the ServiceLoader crash silently and ignore the provider. > {code} > java.util.ServiceConfigurationError: org.jboss.logging.LoggerProvider: Provider org.jboss.logging.Slf4jLoggerProvider could not be instantiated: java.lang.IllegalAccessException: Class java.util.ServiceLoader$LazyIterator can not access a member of class org.jboss.logging.Slf4jLoggerProvider with modifiers "" > at java.util.ServiceLoader.fail(ServiceLoader.java:207) > at java.util.ServiceLoader.access$100(ServiceLoader.java:164) > at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:353) > at java.util.ServiceLoader$1.next(ServiceLoader.java:421) > at org.jboss.logging.LoggerProviders.findProvider(LoggerProviders.java:70) > at org.jboss.logging.LoggerProviders.find(LoggerProviders.java:32) > at org.jboss.logging.LoggerProviders.(LoggerProviders.java:29) > at org.jboss.logging.Logger.getLogger(Logger.java:2177) > at org.jboss.logging.Logger$1.run(Logger.java:2277) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2241) > at org.jboss.logging.Logger.getMessageLogger(Logger.java:2228) > at org.hibernate.cfg.Configuration.(Configuration.java:176) > ... > {code} > This is caused by the fact that all JBoss providers are not public classes and are instead package classes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 05:44:29 2014 From: issues at jboss.org (Mitesh Manani (JIRA)) Date: Thu, 13 Nov 2014 05:44:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) If the WildFly installation directory path contains space then JaxrsSpringProcessor causes NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019659#comment-13019659 ] Mitesh Manani commented on WFLY-4075: ------------------------------------- The space workaround seems to be invalid. i have it installed on my C:\wildfly-9.0.0.Alpha2 > If the WildFly installation directory path contains space then JaxrsSpringProcessor causes NullPointerException > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4075 > URL: https://issues.jboss.org/browse/WFLY-4075 > Project: WildFly > Issue Type: Bug > Components: REST, VFS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Stuart Douglas > > - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: > {code} > 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld > 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) > ... 6 more > Caused by: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) > ... 7 more > 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 06:10:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 06:10:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019665#comment-13019665 ] RH Bugzilla Integration commented on JGRP-1878: ----------------------------------------------- Marek Kopecky changed the Status of [bug 1076015|https://bugzilla.redhat.com/show_bug.cgi?id=1076015] from ON_QA to VERIFIED > Multicast discovery does not work on JDK8 > ----------------------------------------- > > Key: JGRP-1878 > URL: https://issues.jboss.org/browse/JGRP-1878 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.12, 3.5 > Environment: OpenJDK8, OracleJDK8u40 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 3.2.14, 3.6 > > Attachments: mcast.java > > > Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8. > Steps to reproduce with draw, switch to JDK8: > {noformat} > export IP_ADDR=127.0.0.1 > ./draw.sh > export IP_ADDR=192.168.1.10 > ./draw.sh > {noformat} > Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug.. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 06:28:29 2014 From: issues at jboss.org (Jay Kumar SenSharma (JIRA)) Date: Thu, 13 Nov 2014 06:28:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kumar SenSharma updated WFLY-4075: -------------------------------------- Summary: Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException (was: If the WildFly installation directory path contains space then JaxrsSpringProcessor causes NullPointerException ) > Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4075 > URL: https://issues.jboss.org/browse/WFLY-4075 > Project: WildFly > Issue Type: Bug > Components: REST, VFS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Stuart Douglas > > - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: > {code} > 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld > 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) > ... 6 more > Caused by: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) > ... 7 more > 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 06:30:29 2014 From: issues at jboss.org (Jay Kumar SenSharma (JIRA)) Date: Thu, 13 Nov 2014 06:30:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kumar SenSharma updated WFLY-4075: -------------------------------------- Steps to Reproduce: - Start wildfly-9.0.0.Alpha2-SNAPSHOT" - Deploy the application Spring RestEasy integration application to wildfly 9/8. By adding the following entry inside the "web.xml". For testing use the code mentoined in link: http://www.mkyong.com/wp-content/uploads/2011/07/RESTEasyt-Spring-Integration-Example.zip {code} org.jboss.as.jaxrs.enableSpringIntegration true {code} was: - Install wildfly on a path which includes space. Example: "/home/jsensharma/some dir/wildfly-9.0.0.Alpha2-SNAPSHOT" *Notice:* there is a space between "some dir" word. - Deploy the application Spring RestEasy integration application to wildfly 9/8. Workaround Description: (was: - Do not install WildFly in a directory which includes space in the PATH. The complete path of the wildfly installation should not include Space.) > Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4075 > URL: https://issues.jboss.org/browse/WFLY-4075 > Project: WildFly > Issue Type: Bug > Components: REST, VFS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Stuart Douglas > > - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: > {code} > 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld > 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) > ... 6 more > Caused by: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) > ... 7 more > 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 06:31:29 2014 From: issues at jboss.org (Jay Kumar SenSharma (JIRA)) Date: Thu, 13 Nov 2014 06:31:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019670#comment-13019670 ] Jay Kumar SenSharma commented on WFLY-4075: ------------------------------------------- - My bad, I tested in a wrong environment. - I freshly tested the same with the mentioned TestCase by adding the following entry of "context-param" in the web.xml to reproduce this error: {code} org.jboss.as.jaxrs.enableSpringIntegration true {code} > Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4075 > URL: https://issues.jboss.org/browse/WFLY-4075 > Project: WildFly > Issue Type: Bug > Components: REST, VFS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Stuart Douglas > > - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: > {code} > 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld > 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) > ... 6 more > Caused by: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) > ... 7 more > 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 06:32:29 2014 From: issues at jboss.org (Jay Kumar SenSharma (JIRA)) Date: Thu, 13 Nov 2014 06:32:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019670#comment-13019670 ] Jay Kumar SenSharma edited comment on WFLY-4075 at 11/13/14 6:31 AM: --------------------------------------------------------------------- - My bad, I tested in a wrong environment. - I freshly tested the same with the mentioned TestCase by adding the following entry of "context-param" in the web.xml to reproduce this error: {code} org.jboss.as.jaxrs.enableSpringIntegration true {code} That could be one of the reason. was (Author: jaysensharma): - My bad, I tested in a wrong environment. - I freshly tested the same with the mentioned TestCase by adding the following entry of "context-param" in the web.xml to reproduce this error: {code} org.jboss.as.jaxrs.enableSpringIntegration true {code} > Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4075 > URL: https://issues.jboss.org/browse/WFLY-4075 > Project: WildFly > Issue Type: Bug > Components: REST, VFS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Stuart Douglas > > - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: > {code} > 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld > 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) > ... 6 more > Caused by: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) > ... 7 more > 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 07:17:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 07:17:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AS7-3050) RESTEasy: Boolean configuration parameters don't reject non-sense content In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019690#comment-13019690 ] RH Bugzilla Integration commented on AS7-3050: ---------------------------------------------- Weinan Li changed the Status of [bug 899664|https://bugzilla.redhat.com/show_bug.cgi?id=899664] from ASSIGNED to ON_QA > RESTEasy: Boolean configuration parameters don't reject non-sense content > ------------------------------------------------------------------------- > > Key: AS7-3050 > URL: https://issues.jboss.org/browse/AS7-3050 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.0.Beta1b > Reporter: Pavel Janousek > Assignee: Weinan Li > Fix For: Awaiting Volunteers > > > RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. These options which are type of Boolean (= true, false; maybe we should do support for 0 and 1 too), other invalid or non-sense setting should be rejected as invalid deployment description and a such application should not be deployed at all. > Affected options are: > - resteasy.scan > - resteasy.scan.providers > - resteasy.scan.resources > - resteasy.use.builtin.providers -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 07:24:29 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 13 Nov 2014 07:24:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4076) Upgrade HAL to 2.4.7.Final In-Reply-To: References: Message-ID: Harald Pehl created WFLY-4076: --------------------------------- Summary: Upgrade HAL to 2.4.7.Final Key: WFLY-4076 URL: https://issues.jboss.org/browse/WFLY-4076 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 07:25:29 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 13 Nov 2014 07:25:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4077) Upgrade HAL to 2.4.7.Final In-Reply-To: References: Message-ID: Harald Pehl created WFLY-4077: --------------------------------- Summary: Upgrade HAL to 2.4.7.Final Key: WFLY-4077 URL: https://issues.jboss.org/browse/WFLY-4077 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 8.2.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 07:25:30 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 13 Nov 2014 07:25:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4076) Upgrade HAL to 2.4.7.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4076: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6915) > Upgrade HAL to 2.4.7.Final > -------------------------- > > Key: WFLY-4076 > URL: https://issues.jboss.org/browse/WFLY-4076 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 07:25:30 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 13 Nov 2014 07:25:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4077) Upgrade HAL to 2.4.7.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4077: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6916) > Upgrade HAL to 2.4.7.Final > -------------------------- > > Key: WFLY-4077 > URL: https://issues.jboss.org/browse/WFLY-4077 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 08:12:29 2014 From: issues at jboss.org (Stefan Lindner (JIRA)) Date: Thu, 13 Nov 2014 08:12:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4078) Calling methods in SessionBeans of another transaction context In-Reply-To: References: Message-ID: Stefan Lindner created WFLY-4078: ------------------------------------ Summary: Calling methods in SessionBeans of another transaction context Key: WFLY-4078 URL: https://issues.jboss.org/browse/WFLY-4078 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 9.0.0.Alpha1 Environment: Java 8.25 Win7-64bit Reporter: Stefan Lindner Assignee: David Lloyd We have an Application running well on JBoss 5. It's a pure EJB3.0 application, no EJB2 parts. We have JarA.jar with it's own transaction context and JarB.jar with it's own transaction context. Each with it's own datasource. In JarA we have @Entity class EntityA... @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) public EntityA doSomeActionsInContextB() { EntityA object = ; return objct; } In JarB we have SessionBean v = getSessionBeanFromContextA(); EntityA object = v.doSomeActionsInContextB(); In JBoss we simply had to set in server/standard/conf/jbossts-properties.xml to allow nested transactions that made the above possible. Now in 8.1 and 9.0 nightlybuild (calls itself RC3) this is not possible anymore. The error messge is the same as in old JBoss 5 without subtransactions configured: WARN [com.arjuna.ats.arjuna] (default task-33) ARJUNA012140: Adding multiple last resources is disallowed. Trying to add LastResourceRecord(XAOnePhaseResource(LocalXAResourceImpl at 21c99d7b[connectionListener=3b646dfc connectionManager=78a4cb30 warned=false currentXid=< formatId=131077, gtrid_length=45, bqual_length=36, tx_uid=0:ffffc0a8de8a:77959edf:5464a877:785, node_name=VisioDesk-primary, branch_uid=0:ffffc0a8de8a:77959edf:5464a877:78e, subordinatenodename=null, eis_name=java:/VISIONET_COMMON_DS > productName=INGRES productVersion=II 9.2.4 (a64.sol/100) jndiName=java:/VISIONET_COMMON_DS])), but already have LastResourceRecord(XAOnePhaseResource(LocalXAResourceImpl at 3286d1fb[connectionListener=268fa4c6 connectionManager=2664884b warned=false currentXid=< formatId=131077, gtrid_length=45, bqual_length=36, tx_uid=0:ffffc0a8de8a:77959edf:5464a877:785, node_name=VisioDesk-primary, branch_uid=0:ffffc0a8de8a:77959edf:5464a877:78a, subordinatenodename=null, eis_name=java:/VISIODESK_DS > productName=INGRES productVersion=II 9.2.4 (a64.sol/100) jndiName=java:/VISIODESK_DS])) WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-33) SQL Error: 0, SQLState: null ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-33) javax.resource.ResourceException: IJ000457: Unchecked throwable in managedConnectionReconnected() cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener at 3b646dfc[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection at 69d8390d connection handles=0 lastUse=1415882936317 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool at 130ebfdb mcp=SemaphoreArrayListManagedConnectionPool at 65ed5c71[pool=VISIONET_COMMON_DS] xaResource=LocalXAResourceImpl at 21c99d7b[connectionListener=3b646dfc connectionManager=78a4cb30 warned=false currentXid=null productName=INGRES productVersion=II 9.2.4 (a64.sol/100) jndiName=java:/VISIONET_COMMON_DS] txSync=null] And there is no way to set subtransactions allowed. Reading http://www.jboss.org//quickstarts/eap/jts/index.html shows outdated examples not working in Wildfly 8 and 9 No ideas from the community: https://developer.jboss.org/message/909762 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 08:36:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 08:36:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-220) cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019722#comment-13019722 ] RH Bugzilla Integration commented on WFCORE-220: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1103620|https://bugzilla.redhat.com/show_bug.cgi?id=1103620] from ON_QA to VERIFIED > cli system props specified with -Dxxx for jboss-cli.sh/bat are ignored > ---------------------------------------------------------------------- > > Key: WFCORE-220 > URL: https://issues.jboss.org/browse/WFCORE-220 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Scripts > Reporter: Alexey Loubyansky > Assignee: James Perkins > Fix For: 1.0.0.Alpha12 > > > E.g. ./jboss-cli.sh -Djboss.cli.config=/jboss-cli.xml > The system property won't be set, instead the argument will treated as simply a command line argument. > This has to be fixed in the scripts themselves launching the CLI. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 08:46:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 08:46:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019730#comment-13019730 ] RH Bugzilla Integration commented on WFCORE-160: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1145960|https://bugzilla.redhat.com/show_bug.cgi?id=1145960] from ON_QA to ASSIGNED > Bash scripts should not attempt to expand argument properties > ------------------------------------------------------------- > > Key: WFCORE-160 > URL: https://issues.jboss.org/browse/WFCORE-160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha10 > > > Scripts that parse the command line arguments use a pattern like > {code} > while [ "$#" -gt 0 ] > do > case "$1" in > *) > CLI_OPTS="$CLI_OPTS \"$1\"" > ;; > esac > shift > done > {code} > The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 09:51:30 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 13 Nov 2014 09:51:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3253) CXF should not be installing BouncyCastle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019774#comment-13019774 ] David Lloyd commented on WFLY-3253: ----------------------------------- Wow, well that's one way to solve it I guess... :-) > CXF should not be installing BouncyCastle > ----------------------------------------- > > Key: WFLY-3253 > URL: https://issues.jboss.org/browse/WFLY-3253 > Project: WildFly > Issue Type: Bug > Components: Web Services > Reporter: David Lloyd > Assignee: Alessio Soldano > Priority: Critical > Fix For: 9.0.0.Beta1 > > > CXF installs a BouncyCastle provider globally into the security providers list. This is causes performance and other problems when this provider gets chosen for whatever reason to be the system crypto provider for e.g. TLS. > The list of globally installed security providers should be a user concern only. If CXF requires a specific provider for a specific purpose, it should be selecting that provider when constructing the crytpo API object, though generally this is to be discouraged. > Ultimately we want to introduce a configuration in the app server that allows the list of security providers to be specified in some way, without interference from any frameworks that we happen to have installed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 09:59:29 2014 From: issues at jboss.org (Alessio Soldano (JIRA)) Date: Thu, 13 Nov 2014 09:59:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3253) CXF should not be installing BouncyCastle In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019646#comment-13019646 ] Alessio Soldano edited comment on WFLY-3253 at 11/13/14 9:58 AM: ----------------------------------------------------------------- Marking as solved; WFLY-4019 pulls Apache CXF 3.0.2 which is not installing BouncyCastle anymore (it's installing a ThreadLocalSecurityProvider which the ws stack sets and unsets a BC provider instance in, just before and after actual need) was (Author: asoldano): Marking as solved; WFLY-4019 pulls Apache CXF 3.0.2 and is not installing BouncyCastle anymore (it's installing a ThreadLocalSecurityProvider which the ws stack sets and unsets a BC provider instance just before and after actual need) > CXF should not be installing BouncyCastle > ----------------------------------------- > > Key: WFLY-3253 > URL: https://issues.jboss.org/browse/WFLY-3253 > Project: WildFly > Issue Type: Bug > Components: Web Services > Reporter: David Lloyd > Assignee: Alessio Soldano > Priority: Critical > Fix For: 9.0.0.Beta1 > > > CXF installs a BouncyCastle provider globally into the security providers list. This is causes performance and other problems when this provider gets chosen for whatever reason to be the system crypto provider for e.g. TLS. > The list of globally installed security providers should be a user concern only. If CXF requires a specific provider for a specific purpose, it should be selecting that provider when constructing the crytpo API object, though generally this is to be discouraged. > Ultimately we want to introduce a configuration in the app server that allows the list of security providers to be specified in some way, without interference from any frameworks that we happen to have installed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 10:28:31 2014 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Thu, 13 Nov 2014 10:28:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) testConnection should account for deployment classloader In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Maestri closed WFLY-2047. --------------------------------- Resolution: Done > testConnection should account for deployment classloader > -------------------------------------------------------- > > Key: WFLY-2047 > URL: https://issues.jboss.org/browse/WFLY-2047 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Alpha4 > Environment: All > Reporter: Jay Kumar SenSharma > Assignee: Stefano Maestri > Fix For: 9.0.0.Beta1 > > > If a DataSource is created as following: > ++++++++++++++++ > > jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA > oracle > > 1 > 15 > > > Test > testPassword > > > > > oracle.jdbc.driver.OracleDriver > > > org.h2.jdbcx.JdbcDataSource > > > ++++++++++++++++ > Then while testing the DataSource the Wildfly throws the following Exception: > +++++++++++++++++++++ > 16:47:10,498 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final] > at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT] > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21] > at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final] > Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base)) > at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101) > at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229) > at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458) > at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411) > at oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:490) > at oracle.jdbc.driver.T4CConnection.(T4CConnection.java:202) > at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33) > at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474) > at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final] > ++++++++++++++++++++++ -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 10:29:30 2014 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Thu, 13 Nov 2014 10:29:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1968) Connection factory isn't activated in generic-jms-ra.rar resource adapter after server reload with jts transactions mode set. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Maestri resolved WFLY-1968. ----------------------------------- Resolution: Rejected As in comment it's not an issue in WFly > Connection factory isn't activated in generic-jms-ra.rar resource adapter after server reload with jts transactions mode set. > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-1968 > URL: https://issues.jboss.org/browse/WFLY-1968 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Alpha4 > Reporter: Vladimir Rastseluev > Assignee: Stefano Maestri > Fix For: 9.0.0.Beta1 > > > Description of problem: > Start server with configured resource adapter and deployed generic-jms-ra.rar. After server started we can see registered and bound connection factory. > Then we add some changes to the server to set up jts transactions mode by CLI utility. Reload the server. Connection factory isn't registered. > Version-Release number of selected component (if applicable): > EAP 6.1.1.ER4 > generic resource adapter: https://github.com/jbertram/generic-jms-ra > How reproducible: > easy > Steps to Reproduce: > 1. add applied generic-jms-ra.rar file to the $JBOSS_HOME/standalone/deployments directory > 2. unpack applied module and add it to $JBOSS_HOME/modules directory > 3. update module.xml file from org.jboss.as.ee module, adding a new dependency: > "" > 4. update $JBOSS_HOME/standalone/configuration/standalone.xml, adding global modules to : > > > > > 5.configure resource-adapters subsystem this way: > > > > > generic-jms-ra.rar > > XATransaction > > > > java.naming.factory.initial=com.tibco.tibjms.naming.TibjmsInitialContextFactory;java.naming.provider.url=tcp://tibco01.mw.lab.eng.bos.redhat.com:7222 > > > XAQCF > > > > > > > tibco > tibco > > > > > > > > 6. run server $JBOSS_HOME/bin/standalone.sh > see - java:/jms/QueueConnectionFactory is registered > 7. run $JBOSS_HOME/bin/cli.sh > 8. execute commands in cli: > -->/subsystem=jacorb/:write-attribute(name=transactions,value=on) > -->/subsystem=transactions/:write-attribute(name=recovery-listener,value=true) > -->/subsystem=transactions/:write-attribute(name=jts,value=true) > -->:reload > Actual results: > connection factory java:/jms/QueueConnectionFactory isn't registered > Expected results: > connection factory java:/jms/QueueConnectionFactory is registered -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 10:30:30 2014 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Thu, 13 Nov 2014 10:30:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2160) Allow Expression for datasource subsystem enabled property In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Maestri reassigned WFLY-2160: ------------------------------------- Assignee: Jeff Zhang (was: Stefano Maestri) > Allow Expression for datasource subsystem enabled property > ---------------------------------------------------------- > > Key: WFLY-2160 > URL: https://issues.jboss.org/browse/WFLY-2160 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JCA > Affects Versions: 8.0.0.Alpha4 > Reporter: Steven Rose > Assignee: Jeff Zhang > Priority: Minor > Labels: wildfly > Fix For: 9.0.0.Beta1 > > > Currently the datasource sub system does not allow expressions. I would like to be able to do this: and set the ds1.enabled property via a properties file. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 10:37:29 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 13 Nov 2014 10:37:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3995) Add tests for suffix option on size-rotating-file-handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins reassigned WFLY-3995: ----------------------------------- Assignee: James Perkins (was: Petr Kremensky) > Add tests for suffix option on size-rotating-file-handler > --------------------------------------------------------- > > Key: WFLY-3995 > URL: https://issues.jboss.org/browse/WFLY-3995 > Project: WildFly > Issue Type: Enhancement > Reporter: Petr Kremensky > Assignee: James Perkins > > Add tests for WFCORE-113 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 10:38:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 13 Nov 2014 10:38:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-245) Add tests for suffix option on size-rotating-file-handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins moved WFLY-3995 to WFCORE-245: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-245 (was: WFLY-3995) > Add tests for suffix option on size-rotating-file-handler > --------------------------------------------------------- > > Key: WFCORE-245 > URL: https://issues.jboss.org/browse/WFCORE-245 > Project: WildFly Core > Issue Type: Enhancement > Reporter: Petr Kremensky > Assignee: James Perkins > > Add tests for WFCORE-113 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 10:38:31 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 13 Nov 2014 10:38:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-245) Add tests for suffix option on size-rotating-file-handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated WFCORE-245: --------------------------------- Component/s: Logging > Add tests for suffix option on size-rotating-file-handler > --------------------------------------------------------- > > Key: WFCORE-245 > URL: https://issues.jboss.org/browse/WFCORE-245 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: Petr Kremensky > Assignee: James Perkins > > Add tests for WFCORE-113 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 10:48:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 10:48:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1149) Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019818#comment-13019818 ] RH Bugzilla Integration commented on WFLY-1149: ----------------------------------------------- Kabir Khan changed the Status of [bug 923836|https://bugzilla.redhat.com/show_bug.cgi?id=923836] from NEW to MODIFIED > Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open. > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1149 > URL: https://issues.jboss.org/browse/WFLY-1149 > Project: WildFly > Issue Type: Bug > Components: Naming, Test Suite > Environment: IBM JDK 6 (build 20110203_074623) > IBM JDK 7 (build 20120809_118929) > Reporter: Ivo Studensky > Assignee: Jason Greene > Attachments: endpoint_is_not_open_2012-11-26.xml, failed_with_status_cancelled_2012-11-26.xml, test_output_with_trace_logging_in_EndpointCache.xml > > > RemoteNamingTestCase intermittently fails when running on IBM JDK. According to logs the remoting channel had been closed before the endpoint tried to connect to it. Unfortunately, when I was trying to debug this issue the tests always nicely passed. > test.log snippet: > {noformat} > 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" read-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" read-1', selector sun.nio.ch.EPollSelectorImpl at 345642e1 > 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" write-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" write-1', selector sun.nio.ch.EPollSelectorImpl at 1dc68cf2 > 13:16:31,121 DEBUG [org.jboss.naming.remote.client.InitialContextFactory] (main) jboss.naming.client.connect.options. has the following options {org.xnio.Options.SASL_POLICY_NOPLAINTEXT=>false} > 13:16:31,191 ERROR [org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1] (Remoting "config-based-naming-client-endpoint" task-1) Channel end notification received, closing channel Channel ID d1f17196 (outbound) of Remoting connection fd3dcedc to /127.0.0.1:4447 > 13:16:31,204 DEBUG [org.jboss.naming.remote.client.HaRemoteNamingStore] (main) Failed to connect to server remote://127.0.0.1:4447: org.jboss.remoting3.NotOpenException: Endpoint is not open > at org.jboss.remoting3.EndpointImpl.resourceUntick(EndpointImpl.java:182) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:261) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333) > at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105) > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:179) > at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:117) > at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83) > at javax.naming.InitialContext.lookup(InitialContext.java:422) > at org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase.testRemoteLookup(RemoteNamingTestCase.java:74) > {noformat} > server.log snippet: > {noformat} > 13:16:31,025 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "test.jar" > 13:16:31,163 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-3) Channel Opened - Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 > 13:16:31,176 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-4) Chosen version 0x01 > 13:16:31,189 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" read-1) Channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 closed. > 13:16:31,193 INFO [org.jboss.as.naming] (Remoting "thinkpax" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to null > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 10:50:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 10:50:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3905) POJO JAX-WS endpoints should not be processed if packaged in EJB-jar In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019820#comment-13019820 ] RH Bugzilla Integration commented on WFLY-3905: ----------------------------------------------- Jan Bliz??k changed the Status of [bug 1147657|https://bugzilla.redhat.com/show_bug.cgi?id=1147657] from ON_QA to VERIFIED > POJO JAX-WS endpoints should not be processed if packaged in EJB-jar > -------------------------------------------------------------------- > > Key: WFLY-3905 > URL: https://issues.jboss.org/browse/WFLY-3905 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Kyle Lape > Assignee: Kyle Lape > Fix For: 9.0.0.Beta1 > > > If a POJO is defined like this in an EJB-jar: > {code:java} > package com.redhat.gss.ws; > @javax.jws.WebService > public class HelloService { > public String sayHello() { > return "Hello World!"; > } > } > {code} > Deployment structure: > {noformat} > klape at localhost ws-java.jar$ tree > . > ??? com > ??? ??? redhat > ??? ??? gss > ??? ??? ws > ??? ??? HelloService.java > ??? META-INF > ??? MANIFEST.MF > 5 directories, 2 files > klape at localhost ws-java.jar$ > {noformat} > Upon deployment, you get this in the log: > {noformat} > 16:52:51,372 INFO [org.jboss.ws.cxf.metadata] (MSC service thread 1-7) JBWS024061: Adding service endpoint metadata: id=com.redhat.gss.ws.HelloService > address=http://localhost:8080/ws-java/HelloService > implementor=com.redhat.gss.ws.HelloService > serviceName={http://ws.gss.redhat.com/}HelloServiceService > portName={http://ws.gss.redhat.com/}HelloServicePort > annotationWsdlLocation=null > wsdlLocationOverride=null > mtomEnabled=false > 16:52:51,571 INFO [org.apache.cxf.service.factory.ReflectionServiceFactoryBean] (MSC service thread 1-7) Creating Service {http://ws.gss.redhat.com/}HelloServiceService from class com.redhat.gss.ws.HelloService > 16:52:51,879 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-7) Setting the server's publish address to be http://localhost:8080/ws-java/HelloService > 16:52:51,925 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-7) JBWS024074: WSDL published to: file:/home/remote/klape/work/archives/wildfly-8.1.0.Final/standalone/data/wsdl/ws-java.jar/HelloServiceService.wsdl > {noformat} > Yet when you try to get the WSDL at {{http://localhost:8080/ws-java/HelloService?wsdl}} (pulled from the metadata in the log), you get a 404 error. > JBossWS should not be trying to deploy the POJO endpoint from within an EJB-jar. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 11:33:29 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 13 Nov 2014 11:33:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4077) Upgrade HAL to 2.4.7.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4077: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/6950 (was: https://issues.jboss.org/browse/WFLY-4077) > Upgrade HAL to 2.4.7.Final > -------------------------- > > Key: WFLY-4077 > URL: https://issues.jboss.org/browse/WFLY-4077 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 11:33:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 13 Nov 2014 11:33:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SASL-72) Release JBoss SASL 1.0.5.CR1 In-Reply-To: References: Message-ID: Darran Lofthouse created SASL-72: ------------------------------------ Summary: Release JBoss SASL 1.0.5.CR1 Key: SASL-72 URL: https://issues.jboss.org/browse/SASL-72 Project: SASL Provider Issue Type: Release Components: Build Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.5.CR1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 11:54:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 13 Nov 2014 11:54:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-246) Upgrade to JBoss SASL 1.0.5.CR1 In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-246: --------------------------------------- Summary: Upgrade to JBoss SASL 1.0.5.CR1 Key: WFCORE-246 URL: https://issues.jboss.org/browse/WFCORE-246 Project: WildFly Core Issue Type: Component Upgrade Components: Remoting, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha13 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 12:00:31 2014 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 13 Nov 2014 12:00:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4078) Calling methods in SessionBeans of another transaction context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019847#comment-13019847 ] Tom Jenkinson commented on WFLY-4078: ------------------------------------- Hi, This doesn't look like a bug to me. I think we should keep this on the discussion forum for now. Tom > Calling methods in SessionBeans of another transaction context > -------------------------------------------------------------- > > Key: WFLY-4078 > URL: https://issues.jboss.org/browse/WFLY-4078 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Environment: Java 8.25 Win7-64bit > Reporter: Stefan Lindner > Assignee: David Lloyd > > We have an Application running well on JBoss 5. It's a pure EJB3.0 application, no EJB2 parts. > We have JarA.jar with it's own transaction context and JarB.jar with it's own transaction context. Each with it's own datasource. > In JarA we have > @Entity > class EntityA... > @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) > public EntityA doSomeActionsInContextB() { > EntityA object = ; > return objct; > } > In JarB we have > SessionBean v = getSessionBeanFromContextA(); > EntityA object = v.doSomeActionsInContextB(); > In JBoss we simply had to set > > > in server/standard/conf/jbossts-properties.xml to allow nested transactions that made the above possible. > Now in 8.1 and 9.0 nightlybuild (calls itself RC3) this is not possible anymore. > The error messge is the same as in old JBoss 5 without subtransactions configured: > WARN [com.arjuna.ats.arjuna] (default task-33) ARJUNA012140: Adding multiple last resources is disallowed. Trying to add LastResourceRecord(XAOnePhaseResource(LocalXAResourceImpl at 21c99d7b[connectionListener=3b646dfc connectionManager=78a4cb30 warned=false currentXid=< formatId=131077, gtrid_length=45, bqual_length=36, tx_uid=0:ffffc0a8de8a:77959edf:5464a877:785, node_name=VisioDesk-primary, branch_uid=0:ffffc0a8de8a:77959edf:5464a877:78e, subordinatenodename=null, eis_name=java:/VISIONET_COMMON_DS > productName=INGRES productVersion=II 9.2.4 (a64.sol/100) jndiName=java:/VISIONET_COMMON_DS])), but already have LastResourceRecord(XAOnePhaseResource(LocalXAResourceImpl at 3286d1fb[connectionListener=268fa4c6 connectionManager=2664884b warned=false currentXid=< formatId=131077, gtrid_length=45, bqual_length=36, tx_uid=0:ffffc0a8de8a:77959edf:5464a877:785, node_name=VisioDesk-primary, branch_uid=0:ffffc0a8de8a:77959edf:5464a877:78a, subordinatenodename=null, eis_name=java:/VISIODESK_DS > productName=INGRES productVersion=II 9.2.4 (a64.sol/100) jndiName=java:/VISIODESK_DS])) > WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-33) SQL Error: 0, SQLState: null > ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-33) javax.resource.ResourceException: IJ000457: Unchecked throwable in managedConnectionReconnected() cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener at 3b646dfc[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection at 69d8390d connection handles=0 lastUse=1415882936317 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool at 130ebfdb mcp=SemaphoreArrayListManagedConnectionPool at 65ed5c71[pool=VISIONET_COMMON_DS] xaResource=LocalXAResourceImpl at 21c99d7b[connectionListener=3b646dfc connectionManager=78a4cb30 warned=false currentXid=null productName=INGRES productVersion=II 9.2.4 (a64.sol/100) jndiName=java:/VISIONET_COMMON_DS] txSync=null] > And there is no way to set subtransactions allowed. Reading http://www.jboss.org//quickstarts/eap/jts/index.html shows outdated examples not working in Wildfly 8 and 9 > No ideas from the community: https://developer.jboss.org/message/909762 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 12:06:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 13 Nov 2014 12:06:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SASL-71) Add a GSSAPI SaslServer mechanism to wrap the JDK supplied impl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SASL-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved SASL-71. ---------------------------------- Resolution: Done > Add a GSSAPI SaslServer mechanism to wrap the JDK supplied impl > --------------------------------------------------------------- > > Key: SASL-71 > URL: https://issues.jboss.org/browse/SASL-71 > Project: SASL Provider > Issue Type: Feature Request > Components: GSSAPI Mechanism > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.5.CR1 > > > The main purpose of this wrapper is so that it can be passed a factory for obtaining Subjects otherwise the code creating the SaslServer instance is always going to need to be checking what type of SaslServer it is creating and manage the Subjects itself. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 12:06:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 13 Nov 2014 12:06:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SASL-72) Release JBoss SASL 1.0.5.CR1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SASL-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved SASL-72. ---------------------------------- Resolution: Done > Release JBoss SASL 1.0.5.CR1 > ---------------------------- > > Key: SASL-72 > URL: https://issues.jboss.org/browse/SASL-72 > Project: SASL Provider > Issue Type: Release > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.5.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 12:27:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 12:27:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3841) double :remove of connection-property from a DS leave it in wrong state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019858#comment-13019858 ] RH Bugzilla Integration commented on WFLY-3841: ----------------------------------------------- Martin Simka changed the Status of [bug 1024239|https://bugzilla.redhat.com/show_bug.cgi?id=1024239] from ON_QA to VERIFIED > double :remove of connection-property from a DS leave it in wrong state > ----------------------------------------------------------------------- > > Key: WFLY-3841 > URL: https://issues.jboss.org/browse/WFLY-3841 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > Priority: Critical > Fix For: 9.0.0.CR1 > > > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:add(value=foo) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > [standalone at localhost:9990 /] :reload > { > "outcome" => "success", > "result" => undefined > } > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies: > Service jboss.data-source-config.ExampleDS.connection-properties.foo was depended upon by service jboss.data-source-config.ExampleDS", > "rolled-back" => true > } > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS/connection-properties=foo:remove > {"outcome" => "success"} > [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:test-connection-in-pool > { > "outcome" => "failed", > "failure-description" => "WFLYJCA0040: failed to invoke operation: WFLYJCA0042: failed to match pool. Check JndiName: java:jboss/datasources/ExampleDS", > "rolled-back" => true > } -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 12:39:30 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 13 Nov 2014 12:39:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4078) Calling methods in SessionBeans of another transaction context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd resolved WFLY-4078. ------------------------------- Resolution: Rejected I agree, we will continue the discussion there. If actual bugs come out of the discussion we can create JIRAs for them later. > Calling methods in SessionBeans of another transaction context > -------------------------------------------------------------- > > Key: WFLY-4078 > URL: https://issues.jboss.org/browse/WFLY-4078 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.0.Alpha1 > Environment: Java 8.25 Win7-64bit > Reporter: Stefan Lindner > Assignee: David Lloyd > > We have an Application running well on JBoss 5. It's a pure EJB3.0 application, no EJB2 parts. > We have JarA.jar with it's own transaction context and JarB.jar with it's own transaction context. Each with it's own datasource. > In JarA we have > @Entity > class EntityA... > @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) > public EntityA doSomeActionsInContextB() { > EntityA object = ; > return objct; > } > In JarB we have > SessionBean v = getSessionBeanFromContextA(); > EntityA object = v.doSomeActionsInContextB(); > In JBoss we simply had to set > > > in server/standard/conf/jbossts-properties.xml to allow nested transactions that made the above possible. > Now in 8.1 and 9.0 nightlybuild (calls itself RC3) this is not possible anymore. > The error messge is the same as in old JBoss 5 without subtransactions configured: > WARN [com.arjuna.ats.arjuna] (default task-33) ARJUNA012140: Adding multiple last resources is disallowed. Trying to add LastResourceRecord(XAOnePhaseResource(LocalXAResourceImpl at 21c99d7b[connectionListener=3b646dfc connectionManager=78a4cb30 warned=false currentXid=< formatId=131077, gtrid_length=45, bqual_length=36, tx_uid=0:ffffc0a8de8a:77959edf:5464a877:785, node_name=VisioDesk-primary, branch_uid=0:ffffc0a8de8a:77959edf:5464a877:78e, subordinatenodename=null, eis_name=java:/VISIONET_COMMON_DS > productName=INGRES productVersion=II 9.2.4 (a64.sol/100) jndiName=java:/VISIONET_COMMON_DS])), but already have LastResourceRecord(XAOnePhaseResource(LocalXAResourceImpl at 3286d1fb[connectionListener=268fa4c6 connectionManager=2664884b warned=false currentXid=< formatId=131077, gtrid_length=45, bqual_length=36, tx_uid=0:ffffc0a8de8a:77959edf:5464a877:785, node_name=VisioDesk-primary, branch_uid=0:ffffc0a8de8a:77959edf:5464a877:78a, subordinatenodename=null, eis_name=java:/VISIODESK_DS > productName=INGRES productVersion=II 9.2.4 (a64.sol/100) jndiName=java:/VISIODESK_DS])) > WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-33) SQL Error: 0, SQLState: null > ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-33) javax.resource.ResourceException: IJ000457: Unchecked throwable in managedConnectionReconnected() cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener at 3b646dfc[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection at 69d8390d connection handles=0 lastUse=1415882936317 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool at 130ebfdb mcp=SemaphoreArrayListManagedConnectionPool at 65ed5c71[pool=VISIONET_COMMON_DS] xaResource=LocalXAResourceImpl at 21c99d7b[connectionListener=3b646dfc connectionManager=78a4cb30 warned=false currentXid=null productName=INGRES productVersion=II 9.2.4 (a64.sol/100) jndiName=java:/VISIONET_COMMON_DS] txSync=null] > And there is no way to set subtransactions allowed. Reading http://www.jboss.org//quickstarts/eap/jts/index.html shows outdated examples not working in Wildfly 8 and 9 > No ideas from the community: https://developer.jboss.org/message/909762 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 13:07:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 13 Nov 2014 13:07:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2111) Enhance CallbackHandler / Realm Integration with lifecycle callbacks. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFLY-2111. ------------------------------------ Resolution: Out of Date Going to be superceded by Elytron > Enhance CallbackHandler / Realm Integration with lifecycle callbacks. > --------------------------------------------------------------------- > > Key: WFLY-2111 > URL: https://issues.jboss.org/browse/WFLY-2111 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management, Remoting, Security, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: authentication_service > Fix For: 9.0.0.Beta1 > > > The authentication / group loading interaction with security realms is a multi-step process, strictly speaking the realm is not actually involved in making the 'authenticated' decision - instead the callbacks allow the entry point to make that decision. > As it is a multi-step process it is beneficial to cache resources between the steps e.g. connections to servers containing the actual users. > As a bare minimum we need the 'org.jboss.as.domain.management.AuthorizingCallbackHandler' interface to have a method which is called to indicate that clean up can and should occur. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 13:09:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 13 Nov 2014 13:09:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-247) add-user.bat is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-4066 to WFCORE-247: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-247 (was: WFLY-4066) Affects Version/s: (was: 9.0.0.Beta1) Component/s: Domain Management Scripts (was: Domain Management) (was: Scripts) Fix Version/s: 1.0.0.Alpha13 (was: 9.0.0.Beta1) > add-user.bat is broken > ---------------------- > > Key: WFCORE-247 > URL: https://issues.jboss.org/browse/WFCORE-247 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Scripts > Reporter: Juergen Zimmermann > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > > When I invoke "add-user.bat ", then I'm getting this Windows error message (in German): > {code} > "that" kann syntaktisch an dieser Stelle nicht verarbeitet werden. > {code} > The solution is to remove the brackets in line 34, i.e. before: > {code} > echo WARNING: The JBOSS_HOME ("%SANITIZED_JBOSS_HOME%") that this script uses points to a different installation than the one that this script resides in ("%RESOLVED_JBOSS_HOME%"). Unpredictable results may occur. > {code} > After: > {code} > echo WARNING: The JBOSS_HOME "%SANITIZED_JBOSS_HOME%" that this script uses points to a different installation than the one that this script resides in "%RESOLVED_JBOSS_HOME%". Unpredictable results may occur. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 13:11:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 13 Nov 2014 13:11:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-248) add-user for user admin / password admin says password must not match username but should say should In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-3278 to WFCORE-248: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-248 (was: WFLY-3278) Component/s: Domain Management Scripts (was: Domain Management) (was: Scripts) Fix Version/s: 1.0.0.Alpha13 (was: 9.0.0.Beta1) > add-user for user admin / password admin says password must not match username but should say should > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-248 > URL: https://issues.jboss.org/browse/WFCORE-248 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Scripts > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 13:15:32 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 13 Nov 2014 13:15:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-247) add-user.bat is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-247: ------------------------------------ Priority: Minor (was: Major) > add-user.bat is broken > ---------------------- > > Key: WFCORE-247 > URL: https://issues.jboss.org/browse/WFCORE-247 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Scripts > Reporter: Juergen Zimmermann > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 1.0.0.Alpha13 > > > When I invoke "add-user.bat ", then I'm getting this Windows error message (in German): > {code} > "that" kann syntaktisch an dieser Stelle nicht verarbeitet werden. > {code} > The solution is to remove the brackets in line 34, i.e. before: > {code} > echo WARNING: The JBOSS_HOME ("%SANITIZED_JBOSS_HOME%") that this script uses points to a different installation than the one that this script resides in ("%RESOLVED_JBOSS_HOME%"). Unpredictable results may occur. > {code} > After: > {code} > echo WARNING: The JBOSS_HOME "%SANITIZED_JBOSS_HOME%" that this script uses points to a different installation than the one that this script resides in "%RESOLVED_JBOSS_HOME%". Unpredictable results may occur. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 13:48:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 13 Nov 2014 13:48:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-247) add-user.bat failing when JBOSS_HOME does not match current folder In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-247: ------------------------------------ Summary: add-user.bat failing when JBOSS_HOME does not match current folder (was: add-user.bat is broken) > add-user.bat failing when JBOSS_HOME does not match current folder > ------------------------------------------------------------------ > > Key: WFCORE-247 > URL: https://issues.jboss.org/browse/WFCORE-247 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Scripts > Reporter: Juergen Zimmermann > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 1.0.0.Alpha13 > > > When I invoke "add-user.bat ", then I'm getting this Windows error message (in German): > {code} > "that" kann syntaktisch an dieser Stelle nicht verarbeitet werden. > {code} > The solution is to remove the brackets in line 34, i.e. before: > {code} > echo WARNING: The JBOSS_HOME ("%SANITIZED_JBOSS_HOME%") that this script uses points to a different installation than the one that this script resides in ("%RESOLVED_JBOSS_HOME%"). Unpredictable results may occur. > {code} > After: > {code} > echo WARNING: The JBOSS_HOME "%SANITIZED_JBOSS_HOME%" that this script uses points to a different installation than the one that this script resides in "%RESOLVED_JBOSS_HOME%". Unpredictable results may occur. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 14:47:30 2014 From: issues at jboss.org (Bryan Varner (JIRA)) Date: Thu, 13 Nov 2014 14:47:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-90) RemotingConnector thowing RuntimeException for connection timeouts. In-Reply-To: References: Message-ID: Bryan Varner created REMJMX-90: ---------------------------------- Summary: RemotingConnector thowing RuntimeException for connection timeouts. Key: REMJMX-90 URL: https://issues.jboss.org/browse/REMJMX-90 Project: Remoting JMX Issue Type: Bug Components: Connection Reporter: Bryan Varner Assignee: Darran Lofthouse Priority: Critical When attempting to connect, if a timeout occurs, an unchecked RuntimeException is thrown, rather than a checked IOException. My mind cannot conceive how this could possibly be correct. {code} try { serverConnector = JMXConnectorFactory.newJMXConnector(serviceURL, environment); serverConnector.connect(environment); } catch (IOException ioe) { // Code to handle connection / network / failures // This never gets called if the IOFuture status is WAITING... } {code} The problem seems to be: https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/RemotingConnector.java#L243 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 15:07:29 2014 From: issues at jboss.org (Bryan Varner (JIRA)) Date: Thu, 13 Nov 2014 15:07:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-91) AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions. In-Reply-To: References: Message-ID: Bryan Varner created REMJMX-91: ---------------------------------- Summary: AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions. Key: REMJMX-91 URL: https://issues.jboss.org/browse/REMJMX-91 Project: Remoting JMX Issue Type: Bug Reporter: Bryan Varner Assignee: Darran Lofthouse I have a client using a handback object when events are received from remote JMX servers. The handback is a local object instance used in the client, and should be operated on as part of handling specific types of notifications. Rather than scoping this thing in my code all over the place, it was much easier to include it as a handback. This works _perfectly_ with the Oracle RMI client. When I try to use this code against JBoss remoting servers, I get (burried) ClassNotFound Exceptions referencing the name of my class. It appears that ClientConnection is sending serialized copies of the handback object to the server when a notificationListener is added... but why? https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/protocol/v2/ClientConnection.java#L1147 Shouldn't the handback be local to the client? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 15:46:30 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Thu, 13 Nov 2014 15:46:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek reopened WFLY-3651: ------------------------------- Reopening. The "new way" of enabling security manager doesn't help for this issue. BTW. Why was the secman module removed from the testsuite? There were several (ignored) testcases hitting this issue. I'll update the reproducer. > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: permissions-bug-1.0-SNAPSHOT.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 15:47:29 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Thu, 13 Nov 2014 15:47:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek updated WFLY-3651: ------------------------------ Attachment: (was: permissions-bug-1.0-SNAPSHOT.war) > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 15:49:30 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Thu, 13 Nov 2014 15:49:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek updated WFLY-3651: ------------------------------ Attachment: wfly3651.war Attaching a new reproducer. Sources are pushed on GitHub: https://github.com/kwart/secured-webapp-template/tree/WFLY-3651-permissions-xml-not-used > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: wfly3651.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 15:52:29 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Thu, 13 Nov 2014 15:52:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek updated WFLY-3651: ------------------------------ Steps to Reproduce: # store {{wfly3651.war}} to {{/tmp}} # start WildFly with JMS enabled (add {{-secmgr}} as a JBoss Modules argument into {{standalone.sh}}) # deploy the app: {{./jboss-cli.sh -c "deploy /tmp/wfly3651.war"}} # go to http://localhost:8080/wfly3651/ and check the output was:Start WildFly 8.1 with security manager. Deploy application using permissions.xml. Try to use permission allowed by permissions.xml > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: wfly3651.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 16:32:29 2014 From: issues at jboss.org (Roger Lefebvre (JIRA)) Date: Thu, 13 Nov 2014 16:32:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-645) Accumulate returned fact causing NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019903#comment-13019903 ] Roger Lefebvre commented on DROOLS-645: --------------------------------------- I ran both variations of the test case provided above. Equally, both resulted in IndexOutOfBoundsException being thrown. I'm not sure if the trace provides insight but I've posted it below. Running in debug showed that getResult is called four times. Interestingly, with each call, the data list (List) contains one less element. On the forth iteration, there are no elements left and, consequently, the exception is thrown. {code} java.lang.RuntimeException: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at org.drools.core.rule.MultiAccumulate.getResult(MultiAccumulate.java:149) at org.drools.core.rule.MultiAccumulate.getResult(MultiAccumulate.java:17) at org.drools.core.phreak.PhreakAccumulateNode.evaluateResultConstraints(PhreakAccumulateNode.java:673) at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:98) at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:563) at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:534) at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:334) at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:161) at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:116) at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:216) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:91) at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:964) at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1234) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1285) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1258) at com.drools.TempTest.testSortingAccumulate(TempTest.java:39) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) 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:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:604) at java.util.ArrayList.get(ArrayList.java:382) at com.drools.TempTest$TestRetryOldestCallTimeAccumulateFunction.getResult(TempTest.java:147) at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor.getResult(JavaAccumulatorFunctionExecutor.java:144) at org.drools.core.rule.MultiAccumulate.getResult(MultiAccumulate.java:141) ... 38 more {code} > Accumulate returned fact causing NPE > ------------------------------------ > > Key: DROOLS-645 > URL: https://issues.jboss.org/browse/DROOLS-645 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta2 > Environment: Mac OSX (maverick) > Reporter: Roger Lefebvre > Assignee: Mario Fusco > Attachments: RetryOldestCallTimeAccumulateFunction.java, RetryOldestCallTimeAccumulateFunction.java > > > The issue is discussed in https://groups.google.com/forum/?hl=en-GB#!topic/drools-usage/aZU5mXSgHMI. > Here is the gist of it.... > I changed the accumulator to the following and it worked: > accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), $message:oldestRetry( $sm )) > The previous approach was this: > $message:StatusMessage() from accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), oldestRetry( $sm )) > which I thought was the correct or acceptable syntax option. Is there something I have overlooked in the second one ("from"??). It does give me a StatusMessage object but it lacks the underlying properties to allow the subsequent modify to work. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 16:53:29 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 13 Nov 2014 16:53:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019907#comment-13019907 ] David Lloyd commented on WFLY-3651: ----------------------------------- It was removed and replaced with running smoke tests with the security manager enabled, which we do in the CI environment on every PR. Very soon this will be expanded to be the whole test suite, which will be far better coverage than either approach. > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: wfly3651.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 16:54:29 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 13 Nov 2014 16:54:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019908#comment-13019908 ] David Lloyd commented on WFLY-3651: ----------------------------------- Regarding your reproducer - are you certain you have enabled the security manager subsystem? Without this subsystem being enabled, permissions.xml will not be used. > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: wfly3651.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 17:01:30 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 13 Nov 2014 17:01:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019911#comment-13019911 ] David Lloyd commented on WFLY-3651: ----------------------------------- Also I must emphasize one more time that at present, using -secmgr is not supported in WildFly. In WildFly 8, the *only* supported way to enable the security manager is by putting the security manager subsystem in your standalone.xml. Any other approach is *not* supported. For WildFly 9, we are looking into supporting the -secmgr flag *to the start script*, not in the configuration. > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: wfly3651.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 17:05:29 2014 From: issues at jboss.org (Kyle Lape (JIRA)) Date: Thu, 13 Nov 2014 17:05:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-117) Fork Log4J ConosleAppender to simply handling of calls to System.out In-Reply-To: References: Message-ID: Kyle Lape created LOGMGR-117: -------------------------------- Summary: Fork Log4J ConosleAppender to simply handling of calls to System.out Key: LOGMGR-117 URL: https://issues.jboss.org/browse/LOGMGR-117 Project: JBoss Log Manager Issue Type: Enhancement Reporter: Kyle Lape Assignee: James Perkins While the use of {{ConsoleAppender}} in Log4J application logging configurations is discouraged, JBoss could probably do a better job of managing its use. Currently it's possible to encounter a deadlock if thread A invokes {{System.out.println()}} and thread B invokes {{Logger.info()}}. Thread A will get the lock on {{System.out}} (a {{java.io.PrintWriter}}), but then thread B will get the lock on the {{org.apache.log4j.ConsoleAppender}}. Then each thread is waiting on the other's lock. The suggested improvement (discussed with [~jamezp]) is to fork Log4J's {{ConsoleAppender}} so that instead of calling {{System.out.println}}, it calls the real {{stdout}}. *Bonus enhancement*: Drop a {{WARN}} message to the system root logger discouraging the use of {{ConsoleAppender}} in application configurations. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 17:12:29 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 13 Nov 2014 17:12:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-147) Update wildfly-security-manager from 1.0.1.Final to 1.1.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-147: ------------------------------- Summary: Update wildfly-security-manager from 1.0.1.Final to 1.1.0.Final (was: Update wildfly-security-manager from 1.0.1.Final to 1.1.0.Beta1) > Update wildfly-security-manager from 1.0.1.Final to 1.1.0.Final > --------------------------------------------------------------- > > Key: WFCORE-147 > URL: https://issues.jboss.org/browse/WFCORE-147 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: James Perkins > Assignee: James Perkins > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 17:21:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 17:21:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4074) pop3 mail session throws a NoSuchProviderException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019914#comment-13019914 ] RH Bugzilla Integration commented on WFLY-4074: ----------------------------------------------- Kabir Khan changed the Status of [bug 1163150|https://bugzilla.redhat.com/show_bug.cgi?id=1163150] from POST to MODIFIED > pop3 mail session throws a NoSuchProviderException > -------------------------------------------------- > > Key: WFLY-4074 > URL: https://issues.jboss.org/browse/WFLY-4074 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > When configuring a pop3 server in standalone.xml as, the following exception is thrown when reading the mailbox: > {noformat} > Caused by: javax.mail.NoSuchProviderException: Invalid protocol: null > at javax.mail.Session.getProvider(Session.java:440) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > at javax.mail.Session.getStore(Session.java:539) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 17:36:29 2014 From: issues at jboss.org (Kyle Lape (JIRA)) Date: Thu, 13 Nov 2014 17:36:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-249) Wrap the default logging handlers in an AsyncHandler In-Reply-To: References: Message-ID: Kyle Lape created WFCORE-249: -------------------------------- Summary: Wrap the default logging handlers in an AsyncHandler Key: WFCORE-249 URL: https://issues.jboss.org/browse/WFCORE-249 Project: WildFly Core Issue Type: Enhancement Components: Logging Reporter: Kyle Lape Assignee: James Perkins This change could potentially enhance performance under heavier logging loads, but the the disadvantages probably need to be considered first. * Under light logging load, is performance improved much? * How about under medium load? * Under heavy load, the async queue may overflow, causing either one of two sceanrios: ** {{OverflowAction.DISCARD}}: The loss of messages. Probably not the right choice for default. ** {{OverflowAction.BLOCK}}: Threads block until queue clears. Could be argued that async is not much better than plain synchronous logging in this scenario. * If the aync thread crashes, are messages lost? If so, is this much worse than synchronous logging, and how often can an async thread crash? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 17:48:29 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 13 Nov 2014 17:48:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas reassigned WFLY-4075: ------------------------------------ Assignee: Tomaz Cerar (was: Stuart Douglas) This looks like a windows issue, as I can't reproduce. Tomaz can you have a look? > Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4075 > URL: https://issues.jboss.org/browse/WFLY-4075 > Project: WildFly > Issue Type: Bug > Components: REST, VFS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Tomaz Cerar > > - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: > {code} > 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld > 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) > ... 6 more > Caused by: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) > ... 7 more > 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 18:13:29 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Thu, 13 Nov 2014 18:13:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-645) Accumulate returned fact causing NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019923#comment-13019923 ] Mario Fusco commented on DROOLS-645: ------------------------------------ Yes sorry, that's normal. The rule's consequence changes the campaignName of the currently bound StatusMessage, so after 3 firings the list is empty and it thorws the exception. Of course the test is wrong, but I wrote it that way only to prove that the modify was working as expected. > Accumulate returned fact causing NPE > ------------------------------------ > > Key: DROOLS-645 > URL: https://issues.jboss.org/browse/DROOLS-645 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta2 > Environment: Mac OSX (maverick) > Reporter: Roger Lefebvre > Assignee: Mario Fusco > Attachments: RetryOldestCallTimeAccumulateFunction.java, RetryOldestCallTimeAccumulateFunction.java > > > The issue is discussed in https://groups.google.com/forum/?hl=en-GB#!topic/drools-usage/aZU5mXSgHMI. > Here is the gist of it.... > I changed the accumulator to the following and it worked: > accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), $message:oldestRetry( $sm )) > The previous approach was this: > $message:StatusMessage() from accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), oldestRetry( $sm )) > which I thought was the correct or acceptable syntax option. Is there something I have overlooked in the second one ("from"??). It does give me a StatusMessage object but it lacks the underlying properties to allow the subsequent modify to work. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 19:21:29 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Thu, 13 Nov 2014 19:21:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-250) Change CLI GUI to use the streaming API to download log files In-Reply-To: References: Message-ID: James Perkins created WFCORE-250: ------------------------------------ Summary: Change CLI GUI to use the streaming API to download log files Key: WFCORE-250 URL: https://issues.jboss.org/browse/WFCORE-250 Project: WildFly Core Issue Type: Task Components: CLI Reporter: James Perkins Assignee: James Perkins The CLI GUI has an option to list log files and download them. This should use the new logging resources and the new streaming API to download the file. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 21:03:29 2014 From: issues at jboss.org (Radoslav Husar (JIRA)) Date: Thu, 13 Nov 2014 21:03:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-436) Inline JGroups subsystem references to threads subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radoslav Husar updated WFLY-436: -------------------------------- Fix Version/s: 9.0.0.Beta1 > Inline JGroups subsystem references to threads subsystem > -------------------------------------------------------- > > Key: WFLY-436 > URL: https://issues.jboss.org/browse/WFLY-436 > Project: WildFly > Issue Type: Sub-task > Components: Clustering > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Fix For: 9.0.0.Beta1 > > > Currently, the JGroups subsystem defers to the threads subsystem to define thread pools and thread factories. Apparently, this is now frowned upon. Instead, the executors for the default pool, OOB pool, and timer pool should be defined inline. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 21:31:29 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 13 Nov 2014 21:31:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4079) Wildfly does not consider methods with no method-intf element when resolving transaction attributes In-Reply-To: References: Message-ID: Stuart Douglas created WFLY-4079: ------------------------------------ Summary: Wildfly does not consider methods with no method-intf element when resolving transaction attributes Key: WFLY-4079 URL: https://issues.jboss.org/browse/WFLY-4079 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Jason Greene If there is a method without a method-intf the ejb-jar.xml it will not be considered when determining the transaction attribute. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 21:31:29 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 13 Nov 2014 21:31:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4079) Wildfly does not consider methods with no method-intf element when resolving transaction attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas updated WFLY-4079: --------------------------------- Assignee: Stuart Douglas (was: Jason Greene) Component/s: EJB > Wildfly does not consider methods with no method-intf element when resolving transaction attributes > --------------------------------------------------------------------------------------------------- > > Key: WFLY-4079 > URL: https://issues.jboss.org/browse/WFLY-4079 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > If there is a method without a method-intf the ejb-jar.xml it will not be considered when determining the transaction attribute. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 21:46:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 13 Nov 2014 21:46:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4079) Wildfly does not consider methods with no method-intf element when resolving transaction attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4079: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1164060 > Wildfly does not consider methods with no method-intf element when resolving transaction attributes > --------------------------------------------------------------------------------------------------- > > Key: WFLY-4079 > URL: https://issues.jboss.org/browse/WFLY-4079 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > If there is a method without a method-intf the ejb-jar.xml it will not be considered when determining the transaction attribute. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 23:25:29 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 13 Nov 2014 23:25:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-124) Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value In-Reply-To: References: Message-ID: David Lloyd created ELY-124: ------------------------------- Summary: Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value Key: ELY-124 URL: https://issues.jboss.org/browse/ELY-124 Project: WildFly Elytron Issue Type: Task Components: SASL Reporter: David Lloyd Assignee: Darran Lofthouse Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null. If null, the server name is considered "unbound" and the client can select what server name it wants to use. The release notes say: {quote} SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803. {quote} The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803 The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 23:25:29 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 13 Nov 2014 23:25:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-123) Wrapping KeyStore to support storing passwords in standard KeyStores In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated ELY-123: ---------------------------- Description: This should provide a mechanism which is basically compatible to the existing PicketBox Vault mechanism. > Wrapping KeyStore to support storing passwords in standard KeyStores > -------------------------------------------------------------------- > > Key: ELY-123 > URL: https://issues.jboss.org/browse/ELY-123 > Project: WildFly Elytron > Issue Type: Feature Request > Components: KeyStores > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.0.0.Beta1 > > > This should provide a mechanism which is basically compatible to the existing PicketBox Vault mechanism. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 23:30:30 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Thu, 13 Nov 2014 23:30:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-124) Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated ELY-124: ---------------------------- Description: Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null. If null, the server name is considered "unbound" and the client can select what server name it wants to use. The release notes say: {quote} SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803. {quote} The updated JavaDoc says: {quote} serverName - The fully qualified host name of the server to authenticate to, or null if the server is not bound to any specific host name. If the mechanism does not allow an unbound server, a SaslException will be thrown. {quote} The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803 The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI. was: Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null. If null, the server name is considered "unbound" and the client can select what server name it wants to use. The release notes say: {quote} SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803. {quote} The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803 The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI. > Java 8+ supports unbound SASL servers; GSSAPI and DIGEST-MD5 both use this value > -------------------------------------------------------------------------------- > > Key: ELY-124 > URL: https://issues.jboss.org/browse/ELY-124 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: David Lloyd > Assignee: Darran Lofthouse > > Since Java 8, the SaslServerFactory interface has been changed so that the serverName may be null. If null, the server name is considered "unbound" and the client can select what server name it wants to use. > The release notes say: > {quote} > SASL service for multiple host names: When creating a SASL server, the server name can be set to null to denote an unbound server, which means a client can request for the service using any server name. After a context is established, the server can retrieve the name as a negotiated property with the key name SASL.BOUND_SERVER_NAME. See RFE 7110803. > {quote} > The updated JavaDoc says: > {quote} > serverName - The fully qualified host name of the server to authenticate to, or null if the server is not bound to any specific host name. If the mechanism does not allow an unbound server, a SaslException will be thrown. > {quote} > The RFE link is: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7110803 > The two SASL mechanisms in Elytron that would be impacted by this are DIGEST-MD5 and GSSAPI. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 13 23:30:30 2014 From: issues at jboss.org (Jay Kumar SenSharma (JIRA)) Date: Thu, 13 Nov 2014 23:30:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kumar SenSharma updated WFLY-4075: -------------------------------------- Attachment: WFLY-4075_Reproducer_And_Log.zip > Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4075 > URL: https://issues.jboss.org/browse/WFLY-4075 > Project: WildFly > Issue Type: Bug > Components: REST, VFS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Tomaz Cerar > Attachments: WFLY-4075_Reproducer_And_Log.zip > > > - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: > {code} > 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld > 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) > ... 6 more > Caused by: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) > ... 7 more > 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:47:31 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 14 Nov 2014 03:47:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-569) Property reactivity prevents index update In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-569: ------------------------------------------ Fix Version/s: 6.2.0.Beta3 (was: 6.2.0.Beta2) > Property reactivity prevents index update > ----------------------------------------- > > Key: DROOLS-569 > URL: https://issues.jboss.org/browse/DROOLS-569 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Labels: backport-to-6.0.x > Fix For: 6.2.0.Beta3 > > > When a property is part of the pattern matching it can anyway be excluded from the property reactivity with a negative watch. Anyway if the property is also indexed this implies that when the fact is modified it skips not only the modification propagation (as requested) but also the update of the corresponding index causing an inconsistency. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:47:32 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 14 Nov 2014 03:47:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-542) Expose more Commands through the KieCommands API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-542: ------------------------------------------ Fix Version/s: 6.2.0.Beta3 (was: 6.2.0.Beta2) > Expose more Commands through the KieCommands API > ------------------------------------------------ > > Key: DROOLS-542 > URL: https://issues.jboss.org/browse/DROOLS-542 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.1.0.CR1 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 6.2.0.Beta3 > > > Not all Commands are exposed by the KieCommands API interface -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:47:32 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 14 Nov 2014 03:47:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-470) Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest)) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-470: ------------------------------------------ Fix Version/s: 6.2.0.Beta3 (was: 6.2.0.Beta2) > Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest)) > --------------------------------------------------------------------------------------------------- > > Key: DROOLS-470 > URL: https://issues.jboss.org/browse/DROOLS-470 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.1.0.Beta2 > Reporter: Geoffrey De Smet > Assignee: Michael Anstis > Fix For: 6.2.0.Beta3 > > > This DT should work: > ||CONDITION||CONDITION||ACTION| > |$guest : SeatDesignation()|$neighbor : SeatDesignation(isNeighborOf($guest))|| > |guestName == "$param"|guestName == "$param"|doSomething();| > It crashes because of the "SeatDesignation(isNeighborOf($guest))". Only empty parenthesis are allowed. > Failing workaround 1: This workaround (as specified by the docs), does NOT work well, because it adds the same condition (isNeighborOf($guest)) multiple times in the same rule: > ||CONDITION||CONDITION||CONDITION||ACTION| > |$guest : SeatDesignation()|$neighbor : SeatDesignation()||| > |guestName == "$param"|isNeighborOf($guest), guestName == "$param"|isNeighborOf($guest), guestAge == "$param"|doSomething();| > Failing workaround 2: Adding an extra, hidden column with that condition does not work when new rows are added because condition columns with an empty cell are ignored. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:47:32 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 14 Nov 2014 03:47:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-453) Allow KieSession globals configurable via kmodule.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-453: ------------------------------------------ Fix Version/s: 6.2.0.Beta3 (was: 6.2.0.Beta2) > Allow KieSession globals configurable via kmodule.xml > ----------------------------------------------------- > > Key: DROOLS-453 > URL: https://issues.jboss.org/browse/DROOLS-453 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.0.0.Final > Reporter: Anton Giertli > Assignee: Mark Proctor > Fix For: 6.2.0.Beta3 > > > Looking at the current xsd of kmodule.xml > https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.0.x/kie-api/src/main/resources/org/kie/api/kmodule.xsd > It is not possible to configure KieSession globals variables via kmodule.xml. > Given the fact it is already possible to configure almost every KieSession related features like listeners, handlers, loggers, globals, also session related, should be configurable through the kmodule.xml too. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:47:33 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 14 Nov 2014 03:47:33 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-329: ------------------------------------------ Fix Version/s: 6.2.0.Beta3 (was: 6.2.0.Beta2) > ClassFormatException when compile template with latest JDK8 (b114) > ------------------------------------------------------------------ > > Key: DROOLS-329 > URL: https://issues.jboss.org/browse/DROOLS-329 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 6.0.0.CR5 > Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html > Reporter: Marek Posolda > Assignee: Mark Proctor > Fix For: 5.5.1.Final, 6.2.0.Beta3 > > > When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main/java/org/drools/examples/templates/SimpleRuleTemplateExample.java ) > it will throw an exception like this: > {code} > Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format > at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148) > at org.drools.template.parser.DefaultTemplateRuleBase.(DefaultTemplateRuleBase.java:62) > at org.drools.template.parser.TemplateDataListener.(TemplateDataListener.java:74) > at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95) > at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81) > at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84) > at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49) > at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > Caused by: java.lang.RuntimeException: wrong class format > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263) > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102) > at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619) > at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133) > at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444) > at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752) > at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464) > at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389) > at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49) > at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371) > at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46) > at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102) > at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006) > at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842) > at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831) > at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441) > at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419) > at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139) > ... 12 more > Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException > at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.(ClassFileReader.java:372) > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287) > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258) > ... 45 more > {code} > Workaround, which worked for me is to switch to Janino compiler (See Workaround description) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:47:34 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 14 Nov 2014 03:47:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-569) Property reactivity prevents index update In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-569: ------------------------------------------ Fix Version/s: 6.2.0.Final (was: 6.2.0.Beta3) > Property reactivity prevents index update > ----------------------------------------- > > Key: DROOLS-569 > URL: https://issues.jboss.org/browse/DROOLS-569 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Labels: backport-to-6.0.x > Fix For: 6.2.0.Final > > > When a property is part of the pattern matching it can anyway be excluded from the property reactivity with a negative watch. Anyway if the property is also indexed this implies that when the fact is modified it skips not only the modification propagation (as requested) but also the update of the corresponding index causing an inconsistency. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:47:34 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 14 Nov 2014 03:47:34 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-542) Expose more Commands through the KieCommands API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-542: ------------------------------------------ Fix Version/s: 6.2.0.Final (was: 6.2.0.Beta3) > Expose more Commands through the KieCommands API > ------------------------------------------------ > > Key: DROOLS-542 > URL: https://issues.jboss.org/browse/DROOLS-542 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.1.0.CR1 > Reporter: Davide Sottara > Assignee: Davide Sottara > Fix For: 6.2.0.Final > > > Not all Commands are exposed by the KieCommands API interface -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:47:35 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 14 Nov 2014 03:47:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-470) Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest)) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-470: ------------------------------------------ Fix Version/s: 6.2.0.Final (was: 6.2.0.Beta3) > Decision Table (XLS) should support fixed conditions, such as SeatDesignation(isNeighborOf($guest)) > --------------------------------------------------------------------------------------------------- > > Key: DROOLS-470 > URL: https://issues.jboss.org/browse/DROOLS-470 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.1.0.Beta2 > Reporter: Geoffrey De Smet > Assignee: Michael Anstis > Fix For: 6.2.0.Final > > > This DT should work: > ||CONDITION||CONDITION||ACTION| > |$guest : SeatDesignation()|$neighbor : SeatDesignation(isNeighborOf($guest))|| > |guestName == "$param"|guestName == "$param"|doSomething();| > It crashes because of the "SeatDesignation(isNeighborOf($guest))". Only empty parenthesis are allowed. > Failing workaround 1: This workaround (as specified by the docs), does NOT work well, because it adds the same condition (isNeighborOf($guest)) multiple times in the same rule: > ||CONDITION||CONDITION||CONDITION||ACTION| > |$guest : SeatDesignation()|$neighbor : SeatDesignation()||| > |guestName == "$param"|isNeighborOf($guest), guestName == "$param"|isNeighborOf($guest), guestAge == "$param"|doSomething();| > Failing workaround 2: Adding an extra, hidden column with that condition does not work when new rows are added because condition columns with an empty cell are ignored. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:47:35 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 14 Nov 2014 03:47:35 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-453) Allow KieSession globals configurable via kmodule.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-453: ------------------------------------------ Fix Version/s: 6.2.0.Final (was: 6.2.0.Beta3) > Allow KieSession globals configurable via kmodule.xml > ----------------------------------------------------- > > Key: DROOLS-453 > URL: https://issues.jboss.org/browse/DROOLS-453 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.0.0.Final > Reporter: Anton Giertli > Assignee: Mark Proctor > Fix For: 6.2.0.Final > > > Looking at the current xsd of kmodule.xml > https://github.com/droolsjbpm/droolsjbpm-knowledge/blob/6.0.x/kie-api/src/main/resources/org/kie/api/kmodule.xsd > It is not possible to configure KieSession globals variables via kmodule.xml. > Given the fact it is already possible to configure almost every KieSession related features like listeners, handlers, loggers, globals, also session related, should be configurable through the kmodule.xml too. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:47:36 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 14 Nov 2014 03:47:36 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-329) ClassFormatException when compile template with latest JDK8 (b114) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-329: ------------------------------------------ Fix Version/s: 6.2.0.Final (was: 6.2.0.Beta3) > ClassFormatException when compile template with latest JDK8 (b114) > ------------------------------------------------------------------ > > Key: DROOLS-329 > URL: https://issues.jboss.org/browse/DROOLS-329 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 6.0.0.CR5 > Environment: Ubuntu linux, latest JDK1.8 (b114) downloaded from https://jdk8.java.net/download.html > Reporter: Marek Posolda > Assignee: Mark Proctor > Fix For: 5.5.1.Final, 6.2.0.Final > > > When trying to run code for compile templates with latest JDK8 (For instance this example https://github.com/droolsjbpm/drools/blob/master/drools-examples/src/main/java/org/drools/examples/templates/SimpleRuleTemplateExample.java ) > it will throw an exception like this: > {code} > Exception in thread "main" java.lang.RuntimeException: java.lang.RuntimeException: wrong class format > at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:148) > at org.drools.template.parser.DefaultTemplateRuleBase.(DefaultTemplateRuleBase.java:62) > at org.drools.template.parser.TemplateDataListener.(TemplateDataListener.java:74) > at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:95) > at org.drools.decisiontable.ExternalSpreadsheetCompiler.compile(ExternalSpreadsheetCompiler.java:81) > at org.drools.examples.templates.SimpleRuleTemplateExample.buildKBase(SimpleRuleTemplateExample.java:84) > at org.drools.examples.templates.SimpleRuleTemplateExample.executeExample(SimpleRuleTemplateExample.java:49) > at org.drools.examples.templates.SimpleRuleTemplateExample.main(SimpleRuleTemplateExample.java:43) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > Caused by: java.lang.RuntimeException: wrong class format > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:263) > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:203) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102) > at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:122) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1188) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromVariantTypeSignature(LookupEnvironment.java:1244) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeArgumentsFromSignature(LookupEnvironment.java:1031) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.getTypeFromTypeSignature(LookupEnvironment.java:1193) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:495) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:577) > at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:327) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:640) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:619) > at org.eclipse.jdt.internal.compiler.Compiler.accept(Compiler.java:295) > at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:133) > at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:183) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:465) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:519) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:368) > at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:444) > at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:752) > at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:464) > at org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:389) > at org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:49) > at org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:371) > at org.drools.compiler.DialectCompiletimeRegistry.compileAll(DialectCompiletimeRegistry.java:46) > at org.drools.compiler.PackageRegistry.compileAll(PackageRegistry.java:102) > at org.drools.compiler.PackageBuilder.compileAll(PackageBuilder.java:1006) > at org.drools.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:842) > at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:831) > at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:441) > at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:419) > at org.drools.template.parser.DefaultTemplateRuleBase.readRule(DefaultTemplateRuleBase.java:139) > ... 12 more > Caused by: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException > at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.(ClassFileReader.java:372) > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287) > at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258) > ... 45 more > {code} > Workaround, which worked for me is to switch to Janino compiler (See Workaround description) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:47:37 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 14 Nov 2014 03:47:37 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-607) Match.getObjects() should reflect the patterns' order In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Biarnes Kiefer updated DROOLS-607: ------------------------------------------ Fix Version/s: 6.2.0.Final (was: 6.2.0.CR2) > Match.getObjects() should reflect the patterns' order > ----------------------------------------------------- > > Key: DROOLS-607 > URL: https://issues.jboss.org/browse/DROOLS-607 > Project: Drools > Issue Type: Enhancement > Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.0.Final, 6.1.0.Final > Reporter: Davide Sottara > Assignee: Mark Proctor > Priority: Minor > Fix For: 6.2.0.Final > > > if Match.getObjects() is called on a rule with LHS A() B() C(), > the resulting list will have the matching objects in reversed order > - that is, [c, b, a] - making it more difficult to analyze it. > The object's position in the list should reflect the LHS. > The order should be preserved even when subnetworks are present. > For example, A() not B() C() should then result in the list [a, *, c ] -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:54:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 03:54:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-764) Enhance the security realm plug-in mechanism for client-cert / external verification. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019954#comment-13019954 ] RH Bugzilla Integration commented on WFLY-764: ---------------------------------------------- Jan Martiska changed the Status of [bug 953200|https://bugzilla.redhat.com/show_bug.cgi?id=953200] from ON_QA to VERIFIED > Enhance the security realm plug-in mechanism for client-cert / external verification. > ------------------------------------------------------------------------------------- > > Key: WFLY-764 > URL: https://issues.jboss.org/browse/WFLY-764 > Project: WildFly > Issue Type: Task > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Labels: Realm_Management > Fix For: Awaiting Volunteers > > > Currently verification is just based on the defined trust store - this is to take it one step further and allow an optional additional verification. > As a first step will need to ensure we have a suitable Callback from the authenticator to the realm to verify the identity and then this can be passed on to the plug-in. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 03:54:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 03:54:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3580) Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019955#comment-13019955 ] RH Bugzilla Integration commented on WFLY-3580: ----------------------------------------------- Jan Martiska changed the Status of [bug 953200|https://bugzilla.redhat.com/show_bug.cgi?id=953200] from ON_QA to VERIFIED > Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3580 > URL: https://issues.jboss.org/browse/WFLY-3580 > Project: WildFly > Issue Type: Bug > Components: Domain Management, EJB > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection. This makes it impossible to get the certificate for use in a custom login module. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 04:34:29 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Fri, 14 Nov 2014 04:34:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4080) maven-wildfly-plugin: deploying without a widlfy running doesn't give a clear error message In-Reply-To: References: Message-ID: Geoffrey De Smet created WFLY-4080: -------------------------------------- Summary: maven-wildfly-plugin: deploying without a widlfy running doesn't give a clear error message Key: WFLY-4080 URL: https://issues.jboss.org/browse/WFLY-4080 Project: WildFly Issue Type: Enhancement Affects Versions: 8.1.0.Final Reporter: Geoffrey De Smet Assignee: Jason Greene "mvn wildfly:deploy" without first starting the wildfly server (I though it did that too) gives a long, convoluted error message about a timeout. Instead it should also say clearly " Check if you already started your WidlFly server on ip:port." -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 04:36:30 2014 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Fri, 14 Nov 2014 04:36:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek resolved WFLY-3651. -------------------------------- Resolution: Won't Fix Ok, I found the way. You really need only to add security manager subsystem into standalone.xml. No -secmgr needed. This works for me: {code:xml} ... ... ... ... {code} *Needs to be documented.* > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: wfly3651.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 04:37:29 2014 From: issues at jboss.org (Ondrej Kotek (JIRA)) Date: Fri, 14 Nov 2014 04:37:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondrej Kotek closed WFLY-3651. ------------------------------ Needs to be documented. > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: wfly3651.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 04:41:30 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Fri, 14 Nov 2014 04:41:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4081) Do not force that the exploded directory ends with ".war" In-Reply-To: References: Message-ID: Geoffrey De Smet created WFLY-4081: -------------------------------------- Summary: Do not force that the exploded directory ends with ".war" Key: WFLY-4081 URL: https://issues.jboss.org/browse/WFLY-4081 Project: WildFly Issue Type: Enhancement Reporter: Geoffrey De Smet Assignee: Jason Greene In a standard webapp, maven creates the following directory and file: // Exploded directory target/mywebapp-1.0/ // War file target/mywebapp-1.0.war *Unfortunately, WildFly forces that exploded directories should have the suffix ".war"*. At least the IntelliJ JBoss app server plugin enforces this, if that's no longer the case, they should fix it asap. This has 2 side effects: 1) Every noob fails to deploy an exploded dir to WildFly in IntelliJ. By the time they realize that it's because they haven't adjusted the exploded artifact's output path, they're already using Jetty or Tomcat (which "just work" in IntelliJ). 2) As a result, maven and IntelliJ are potentially incompatible for WildFly: If you just suffix the exploded directory with ".war", the exploded directory clashes with maven's war file. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 04:53:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 04:53:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-950) RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019983#comment-13019983 ] RH Bugzilla Integration commented on WFLY-950: ---------------------------------------------- Katerina Novotna changed the Status of [bug 899666|https://bugzilla.redhat.com/show_bug.cgi?id=899666] from ON_QA to VERIFIED > RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception > --------------------------------------------------------------------- > > Key: WFLY-950 > URL: https://issues.jboss.org/browse/WFLY-950 > Project: WildFly > Issue Type: Bug > Components: REST > Reporter: Pavel Janousek > Assignee: Weinan Li > > RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. The major one (also portable defined by JAX-RS standard) is _javax.ws.rs.Application_. When I set this parameter to empty content present behavior is raising exception "java.lang.StringIndexOutOfBoundsException: String index out of range: 0", it is not so good. > I think, this is hard miss-configuration error and deployment description as this one should be rejected and a such application should not be deployed at all with appropriate error message, but not only by messed exception. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 05:15:32 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Fri, 14 Nov 2014 05:15:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019986#comment-13019986 ] Tomaz Cerar commented on WFLY-3651: ----------------------------------- If you build server with -Dsecurity.manager it will include security manager subsystem by default and as such run testsuite with it. > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: wfly3651.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 05:36:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 05:36:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3972) Missing security domain dependency In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019996#comment-13019996 ] RH Bugzilla Integration commented on WFLY-3972: ----------------------------------------------- Hayk Hovsepyan changed the Status of [bug 1152105|https://bugzilla.redhat.com/show_bug.cgi?id=1152105] from ON_QA to VERIFIED > Missing security domain dependency > ---------------------------------- > > Key: WFLY-3972 > URL: https://issues.jboss.org/browse/WFLY-3972 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.1.0.Final > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > Priority: Critical > Fix For: 8.2.0.CR1, 9.0.0.CR1 > > > Only DataSourceEnable appears to have a dependency defined against the security domain used (SecurityDomainService). > Also any security domain used in recovery needs a dependency. > Likewise for resource adapter deployments. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 05:59:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 05:59:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-156) Defer the WFLY-184 validation until service start In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020002#comment-13020002 ] RH Bugzilla Integration commented on WFCORE-156: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1149612|https://bugzilla.redhat.com/show_bug.cgi?id=1149612] from ON_QA to VERIFIED > Defer the WFLY-184 validation until service start > ------------------------------------------------- > > Key: WFCORE-156 > URL: https://issues.jboss.org/browse/WFCORE-156 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha10 > > > The WFLY-184 fix rejects the combination of any-ipv6-address and java.net.preferIPv4Stack=true in Stage.RUNTIME, but does so during service installation rather than in service start. The effect of this is failures occur even if the interface resource isn't being used; e.g. on a host controller. > This also leads to inconsistent behavior between "add" and "write-attribute", as the write-attribute handler doesn't install the service, and thus doesn't fail. It just sets reload-required. > Fix is to move the check into NetworkInterfaceService.start() and to make those services ON_DEMAND so the check won't occur until the interface is actually needed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 06:11:29 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Fri, 14 Nov 2014 06:11:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4082) Upgrade Generic JMS RA to 1.0.7.Final In-Reply-To: References: Message-ID: Jeff Mesnil created WFLY-4082: --------------------------------- Summary: Upgrade Generic JMS RA to 1.0.7.Final Key: WFLY-4082 URL: https://issues.jboss.org/browse/WFLY-4082 Project: WildFly Issue Type: Component Upgrade Components: JMS Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 06:19:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 06:19:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4082) Upgrade Generic JMS RA to 1.0.7.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4082: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1164213 > Upgrade Generic JMS RA to 1.0.7.Final > ------------------------------------- > > Key: WFLY-4082 > URL: https://issues.jboss.org/browse/WFLY-4082 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 07:27:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 07:27:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4082) Upgrade Generic JMS RA to 1.0.7.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020027#comment-13020027 ] RH Bugzilla Integration commented on WFLY-4082: ----------------------------------------------- Jeff Mesnil changed the Status of [bug 1164213|https://bugzilla.redhat.com/show_bug.cgi?id=1164213] from NEW to POST > Upgrade Generic JMS RA to 1.0.7.Final > ------------------------------------- > > Key: WFLY-4082 > URL: https://issues.jboss.org/browse/WFLY-4082 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 07:49:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 07:49:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3580) Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020036#comment-13020036 ] RH Bugzilla Integration commented on WFLY-3580: ----------------------------------------------- Dominik Pospisil changed the Status of [bug 1123505|https://bugzilla.redhat.com/show_bug.cgi?id=1123505] from POST to MODIFIED > Remoting LoginModule does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3580 > URL: https://issues.jboss.org/browse/WFLY-3580 > Project: WildFly > Issue Type: Bug > Components: Domain Management, EJB > Reporter: Derek Horton > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > EJB/remoting configuration does not propagate the certificate as credentials for authentication if mutual auth SSL was used for the connection. This makes it impossible to get the certificate for use in a custom login module. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 07:49:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 07:49:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-764) Enhance the security realm plug-in mechanism for client-cert / external verification. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020037#comment-13020037 ] RH Bugzilla Integration commented on WFLY-764: ---------------------------------------------- Dominik Pospisil changed the Status of [bug 1123505|https://bugzilla.redhat.com/show_bug.cgi?id=1123505] from POST to MODIFIED > Enhance the security realm plug-in mechanism for client-cert / external verification. > ------------------------------------------------------------------------------------- > > Key: WFLY-764 > URL: https://issues.jboss.org/browse/WFLY-764 > Project: WildFly > Issue Type: Task > Components: Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Labels: Realm_Management > Fix For: Awaiting Volunteers > > > Currently verification is just based on the defined trust store - this is to take it one step further and allow an optional additional verification. > As a first step will need to ensure we have a suitable Callback from the authenticator to the realm to verify the identity and then this can be passed on to the plug-in. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 08:08:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 08:08:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020051#comment-13020051 ] RH Bugzilla Integration commented on WFLY-4054: ----------------------------------------------- Amos Feng changed the Status of [bug 1156032|https://bugzilla.redhat.com/show_bug.cgi?id=1156032] from NEW to POST > Unexpected attribute can be added to elements in Transactions Subsystem > ----------------------------------------------------------------------- > > Key: WFLY-4054 > URL: https://issues.jboss.org/browse/WFLY-4054 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. > When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 08:47:29 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 14 Nov 2014 08:47:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020060#comment-13020060 ] David Lloyd commented on WFLY-3651: ----------------------------------- Note however, that the *full* test suite does not pass completely under the security manager (pending some wildfly-core PRs and a few remaining fixes). As I said above though, *soon* it will be the norm for testing pull requests. > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: wfly3651.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:01:29 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Fri, 14 Nov 2014 09:01:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4083) Upgrade Infinispan to 6.0.3.Final In-Reply-To: References: Message-ID: Paul Ferraro created WFLY-4083: ---------------------------------- Summary: Upgrade Infinispan to 6.0.3.Final Key: WFLY-4083 URL: https://issues.jboss.org/browse/WFLY-4083 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 8.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 8.2.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:10:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:10:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-90) RemotingConnector thowing RuntimeException for connection timeouts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-90: ----------------------------------- Description: When attempting to connect, if a timeout occurs, an unchecked RuntimeException is thrown, rather than a checked IOException. {code} try { serverConnector = JMXConnectorFactory.newJMXConnector(serviceURL, environment); serverConnector.connect(environment); } catch (IOException ioe) { // Code to handle connection / network / failures // This never gets called if the IOFuture status is WAITING... } {code} The problem seems to be: https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/RemotingConnector.java#L243 was: When attempting to connect, if a timeout occurs, an unchecked RuntimeException is thrown, rather than a checked IOException. My mind cannot conceive how this could possibly be correct. {code} try { serverConnector = JMXConnectorFactory.newJMXConnector(serviceURL, environment); serverConnector.connect(environment); } catch (IOException ioe) { // Code to handle connection / network / failures // This never gets called if the IOFuture status is WAITING... } {code} The problem seems to be: https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/RemotingConnector.java#L243 > RemotingConnector thowing RuntimeException for connection timeouts. > ------------------------------------------------------------------- > > Key: REMJMX-90 > URL: https://issues.jboss.org/browse/REMJMX-90 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Reporter: Bryan Varner > Assignee: Darran Lofthouse > Priority: Critical > > When attempting to connect, if a timeout occurs, an unchecked RuntimeException is thrown, rather than a checked IOException. > {code} > try { > serverConnector = JMXConnectorFactory.newJMXConnector(serviceURL, environment); > serverConnector.connect(environment); > } catch (IOException ioe) { > // Code to handle connection / network / failures > // This never gets called if the IOFuture status is WAITING... > } > {code} > The problem seems to be: > https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/RemotingConnector.java#L243 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:10:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:10:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-90) RemotingConnector thowing RuntimeException for connection timeouts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-90: ----------------------------------- Workaround Description: Catch unchecked Exceptions. (was: Catch unchecked Exceptions... *blech*) > RemotingConnector thowing RuntimeException for connection timeouts. > ------------------------------------------------------------------- > > Key: REMJMX-90 > URL: https://issues.jboss.org/browse/REMJMX-90 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Reporter: Bryan Varner > Assignee: Darran Lofthouse > Priority: Critical > > When attempting to connect, if a timeout occurs, an unchecked RuntimeException is thrown, rather than a checked IOException. > {code} > try { > serverConnector = JMXConnectorFactory.newJMXConnector(serviceURL, environment); > serverConnector.connect(environment); > } catch (IOException ioe) { > // Code to handle connection / network / failures > // This never gets called if the IOFuture status is WAITING... > } > {code} > The problem seems to be: > https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/RemotingConnector.java#L243 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:10:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:10:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-90) RemotingConnector thowing RuntimeException for connection timeouts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-90: ----------------------------------- Priority: Major (was: Critical) > RemotingConnector thowing RuntimeException for connection timeouts. > ------------------------------------------------------------------- > > Key: REMJMX-90 > URL: https://issues.jboss.org/browse/REMJMX-90 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Reporter: Bryan Varner > Assignee: Darran Lofthouse > > When attempting to connect, if a timeout occurs, an unchecked RuntimeException is thrown, rather than a checked IOException. > {code} > try { > serverConnector = JMXConnectorFactory.newJMXConnector(serviceURL, environment); > serverConnector.connect(environment); > } catch (IOException ioe) { > // Code to handle connection / network / failures > // This never gets called if the IOFuture status is WAITING... > } > {code} > The problem seems to be: > https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/RemotingConnector.java#L243 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:10:31 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:10:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-90) RemotingConnector thowing RuntimeException for connection timeouts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-90: ----------------------------------- Fix Version/s: 2.0.1.CR2 > RemotingConnector thowing RuntimeException for connection timeouts. > ------------------------------------------------------------------- > > Key: REMJMX-90 > URL: https://issues.jboss.org/browse/REMJMX-90 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Reporter: Bryan Varner > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR2 > > > When attempting to connect, if a timeout occurs, an unchecked RuntimeException is thrown, rather than a checked IOException. > {code} > try { > serverConnector = JMXConnectorFactory.newJMXConnector(serviceURL, environment); > serverConnector.connect(environment); > } catch (IOException ioe) { > // Code to handle connection / network / failures > // This never gets called if the IOFuture status is WAITING... > } > {code} > The problem seems to be: > https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/RemotingConnector.java#L243 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:11:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:11:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-91) AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-91: ----------------------------------- Affects Version/s: 2.0.1.CR1 > AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions. > ------------------------------------------------------------------------------------------------------------ > > Key: REMJMX-91 > URL: https://issues.jboss.org/browse/REMJMX-91 > Project: Remoting JMX > Issue Type: Bug > Affects Versions: 2.0.1.CR1 > Reporter: Bryan Varner > Assignee: Darran Lofthouse > > I have a client using a handback object when events are received from remote JMX servers. > The handback is a local object instance used in the client, and should be operated on as part of handling specific types of notifications. Rather than scoping this thing in my code all over the place, it was much easier to include it as a handback. > This works _perfectly_ with the Oracle RMI client. When I try to use this code against JBoss remoting servers, I get (burried) ClassNotFound Exceptions referencing the name of my class. > It appears that ClientConnection is sending serialized copies of the handback object to the server when a notificationListener is added... but why? > https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/protocol/v2/ClientConnection.java#L1147 > Shouldn't the handback be local to the client? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:12:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:12:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-91) AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-91: ----------------------------------- Fix Version/s: 2.0.1.CR2 > AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions. > ------------------------------------------------------------------------------------------------------------ > > Key: REMJMX-91 > URL: https://issues.jboss.org/browse/REMJMX-91 > Project: Remoting JMX > Issue Type: Bug > Affects Versions: 2.0.1.CR1 > Reporter: Bryan Varner > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR2 > > > I have a client using a handback object when events are received from remote JMX servers. > The handback is a local object instance used in the client, and should be operated on as part of handling specific types of notifications. Rather than scoping this thing in my code all over the place, it was much easier to include it as a handback. > This works _perfectly_ with the Oracle RMI client. When I try to use this code against JBoss remoting servers, I get (burried) ClassNotFound Exceptions referencing the name of my class. > It appears that ClientConnection is sending serialized copies of the handback object to the server when a notificationListener is added... but why? > https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/protocol/v2/ClientConnection.java#L1147 > Shouldn't the handback be local to the client? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:12:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:12:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-91) AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-91: ----------------------------------- Component/s: Notifications > AddNotificationListener is serializing the handback object to the server -- causing ClassNotFoundExceptions. > ------------------------------------------------------------------------------------------------------------ > > Key: REMJMX-91 > URL: https://issues.jboss.org/browse/REMJMX-91 > Project: Remoting JMX > Issue Type: Bug > Components: Notifications > Affects Versions: 2.0.1.CR1 > Reporter: Bryan Varner > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR2 > > > I have a client using a handback object when events are received from remote JMX servers. > The handback is a local object instance used in the client, and should be operated on as part of handling specific types of notifications. Rather than scoping this thing in my code all over the place, it was much easier to include it as a handback. > This works _perfectly_ with the Oracle RMI client. When I try to use this code against JBoss remoting servers, I get (burried) ClassNotFound Exceptions referencing the name of my class. > It appears that ClientConnection is sending serialized copies of the handback object to the server when a notificationListener is added... but why? > https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/protocol/v2/ClientConnection.java#L1147 > Shouldn't the handback be local to the client? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:13:30 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:13:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-90) RemotingConnector thowing RuntimeException for connection timeouts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-90: ----------------------------------- Affects Version/s: 2.0.1.CR1 > RemotingConnector thowing RuntimeException for connection timeouts. > ------------------------------------------------------------------- > > Key: REMJMX-90 > URL: https://issues.jboss.org/browse/REMJMX-90 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 2.0.1.CR1 > Reporter: Bryan Varner > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR2 > > > When attempting to connect, if a timeout occurs, an unchecked RuntimeException is thrown, rather than a checked IOException. > {code} > try { > serverConnector = JMXConnectorFactory.newJMXConnector(serviceURL, environment); > serverConnector.connect(environment); > } catch (IOException ioe) { > // Code to handle connection / network / failures > // This never gets called if the IOFuture status is WAITING... > } > {code} > The problem seems to be: > https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/RemotingConnector.java#L243 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:22:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 09:22:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2912) Generic JMS adapter does not deploy correctly in domain mode. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020088#comment-13020088 ] RH Bugzilla Integration commented on WFLY-2912: ----------------------------------------------- Ond?ej Kalman changed the Status of [bug 1070106|https://bugzilla.redhat.com/show_bug.cgi?id=1070106] from NEW to VERIFIED > Generic JMS adapter does not deploy correctly in domain mode. > ------------------------------------------------------------- > > Key: WFLY-2912 > URL: https://issues.jboss.org/browse/WFLY-2912 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Final > Reporter: Tom Ross > Assignee: Stefano Maestri > Fix For: 8.1.0.CR1, 8.1.0.Final > > > When trying to use generic resource adapter with third part JMS providers like TIBCO it is necessary to use generic RA provided in JBoss EAP 6.2. Unfortunately it would appear that when trying to use in domain mode the RA does not get deployed full, though it works perfectly in standalone mode. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:22:31 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:22:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-4) Allow for long method calls within the protocol. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-4: ---------------------------------- Fix Version/s: 2.0.1.CR3 (was: 2.0.1.CR2) > Allow for long method calls within the protocol. > ------------------------------------------------ > > Key: REMJMX-4 > URL: https://issues.jboss.org/browse/REMJMX-4 > Project: Remoting JMX > Issue Type: Task > Components: Connection, RPC > Reporter: Darran Lofthouse > Fix For: 2.0.1.CR3 > > > Methods such as invoke could take a long time to return depending on what the MBean is actually doing. > This task is to build support for this into the protocol, 2 initial ideas are: - > 1 - Allow the client to 'ping' the server after a request has timed out and ask the server is this request still running, server side the we can track the correlation IDs of current requests an check it is still in-progress. > 2 - The server could periodically send a message to the client to say the message is still in progress, the client could cache these and on timing out check if one has been received recently and wait again if one has. > 3 - Any other suggestions? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:22:31 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:22:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-83) The remoting-jmx 2.0.0.Final artifact's dependencies are not available in Maven Central In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-83: ----------------------------------- Fix Version/s: 2.0.1.CR3 > The remoting-jmx 2.0.0.Final artifact's dependencies are not available in Maven Central > --------------------------------------------------------------------------------------- > > Key: REMJMX-83 > URL: https://issues.jboss.org/browse/REMJMX-83 > Project: Remoting JMX > Issue Type: Bug > Components: Build > Affects Versions: 2.0.0.Final > Reporter: Tomas Repel > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR3 > > > The org.jboss.remotingjmx:remoting-jmx:2.0.0.Final artifact is available in Maven Central but it has dependencies that are not available in Maven Central, for instance org.jboss.remoting:jboss-remoting:jar:4.0.0.Beta3 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:22:32 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:22:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-78) Make XNIO and Remoting options be configurable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-78: ----------------------------------- Fix Version/s: 2.0.1.CR3 > Make XNIO and Remoting options be configurable > ---------------------------------------------- > > Key: REMJMX-78 > URL: https://issues.jboss.org/browse/REMJMX-78 > Project: Remoting JMX > Issue Type: Feature Request > Affects Versions: 1.1.0.Final > Environment: EAP 6.1.1 > Reporter: Osamu Nagano > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR3 > > > Properties passed via "env" in "JMXConnectorFactory.connect(serviceURL, env)" is very limited. And it is not passed to XNIO and Remoting like in line 192 below. It is more flexible if those are configurable like in jboss-ejb-client project. > https://github.com/jbossas/remoting-jmx/blob/1.1.0.Final/src/main/java/org/jboss/remotingjmx/RemotingConnector.java#L185 > {code} > 191 final Xnio xnio = Xnio.getInstance(); > 192 endpoint = Remoting.createEndpoint("endpoint", xnio, OptionMap.create(Options.THREAD_DAEMON, true)); > 193 endpoint.addConnectionProvider(CONNECTION_PROVIDER_URI, new RemoteConnectionProviderFactory(), OptionMap.EMPTY); > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:22:32 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:22:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-81) Add http-remoting-jmx testing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-81: ----------------------------------- Fix Version/s: 2.0.1.CR3 (was: 2.0.1.CR2) > Add http-remoting-jmx testing > ----------------------------- > > Key: REMJMX-81 > URL: https://issues.jboss.org/browse/REMJMX-81 > Project: Remoting JMX > Issue Type: Task > Components: Tests > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR3 > > > Connecting over HTTP is now the default mode for WildFly yet we have no testing of this within the Remoting JMX project itself. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:22:32 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 09:22:32 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-85) Add support for remote:// remote+http:// and remote+https:// URI schemes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated REMJMX-85: ----------------------------------- Fix Version/s: 2.0.1.CR3 (was: 2.0.1.CR2) > Add support for remote:// remote+http:// and remote+https:// URI schemes > ------------------------------------------------------------------------ > > Key: REMJMX-85 > URL: https://issues.jboss.org/browse/REMJMX-85 > Project: Remoting JMX > Issue Type: Enhancement > Components: Connection > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.1.CR3 > > > Remaining schemes should be deprecated. > Note: Drop the JMX from the scheme as it is redundant. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:25:29 2014 From: issues at jboss.org (Tom Fonteyne (JIRA)) Date: Fri, 14 Nov 2014 09:25:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4084) cli tab completion gets confused by double slash In-Reply-To: References: Message-ID: Tom Fonteyne created WFLY-4084: ---------------------------------- Summary: cli tab completion gets confused by double slash Key: WFLY-4084 URL: https://issues.jboss.org/browse/WFLY-4084 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: 9.0.0.Alpha1 Reporter: Tom Fonteyne Assignee: Alexey Loubyansky Priority: Minor Using two slashes in a CLI path and hitting TAB confuses the auto-completion -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 09:28:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 09:28:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4084) cli tab completion gets confused by double slash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4084: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1164277 > cli tab completion gets confused by double slash > ------------------------------------------------ > > Key: WFLY-4084 > URL: https://issues.jboss.org/browse/WFLY-4084 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Fonteyne > Assignee: Alexey Loubyansky > Priority: Minor > > Using two slashes in a CLI path and hitting TAB confuses the auto-completion -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:05:29 2014 From: issues at jboss.org (=?UTF-8?Q?victor_fran=C3=A7a_=28JIRA=29?=) Date: Fri, 14 Nov 2014 10:05:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4085) XML Marshalling problems without -jaxpmodule on start scrtipts. In-Reply-To: References: Message-ID: victor fran?a created WFLY-4085: ----------------------------------- Summary: XML Marshalling problems without -jaxpmodule on start scrtipts. Key: WFLY-4085 URL: https://issues.jboss.org/browse/WFLY-4085 Project: WildFly Issue Type: Quality Risk Components: XML Frameworks Affects Versions: 8.1.0.Final Reporter: victor fran?a Assignee: Jason Greene I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. So, i realized that the problem just comes up if i start directly via standalone.sh. Then i decided to compare standalone.sh and eclipse's configurations for wilffly initialization. The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on wildfly 8.1.0.final. A found another issue about this parameter removing here WFLY-425. Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. Best regards! -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:06:29 2014 From: issues at jboss.org (=?UTF-8?Q?victor_fran=C3=A7a_=28JIRA=29?=) Date: Fri, 14 Nov 2014 10:06:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4085) XML Marshalling problems without -jaxpmodule on start scrtipts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] victor fran?a updated WFLY-4085: -------------------------------- Description: I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. So, i realized that the problem just comes up if i start directly via standalone.sh. Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on wildfly 8.1.0.final. A found another issue about this parameter removing here WFLY-425. Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. Best regards! was: I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. So, i realized that the problem just comes up if i start directly via standalone.sh. Then i decided to compare standalone.sh and eclipse's configurations for wilffly initialization. The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on wildfly 8.1.0.final. A found another issue about this parameter removing here WFLY-425. Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. Best regards! > XML Marshalling problems without -jaxpmodule on start scrtipts. > --------------------------------------------------------------- > > Key: WFLY-4085 > URL: https://issues.jboss.org/browse/WFLY-4085 > Project: WildFly > Issue Type: Quality Risk > Components: XML Frameworks > Affects Versions: 8.1.0.Final > Reporter: victor fran?a > Assignee: Jason Greene > Labels: jaxb, jaxpmodule, marshalling, xml > > I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. > The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. > Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. > So, i realized that the problem just comes up if i start directly via standalone.sh. > Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. > The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on wildfly 8.1.0.final. > A found another issue about this parameter removing here WFLY-425. > Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. > Best regards! -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:06:30 2014 From: issues at jboss.org (=?UTF-8?Q?victor_fran=C3=A7a_=28JIRA=29?=) Date: Fri, 14 Nov 2014 10:06:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4085) XML Marshalling problems without -jaxpmodule on start scrtipts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] victor fran?a updated WFLY-4085: -------------------------------- Description: I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. So, i realized that the problem just comes up if i start directly via standalone.sh. Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on wildfly 8.1.0.final standalone.sh. A found another issue about this parameter removing here WFLY-425. Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. Best regards! was: I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. So, i realized that the problem just comes up if i start directly via standalone.sh. Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on wildfly 8.1.0.final. A found another issue about this parameter removing here WFLY-425. Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. Best regards! > XML Marshalling problems without -jaxpmodule on start scrtipts. > --------------------------------------------------------------- > > Key: WFLY-4085 > URL: https://issues.jboss.org/browse/WFLY-4085 > Project: WildFly > Issue Type: Quality Risk > Components: XML Frameworks > Affects Versions: 8.1.0.Final > Reporter: victor fran?a > Assignee: Jason Greene > Labels: jaxb, jaxpmodule, marshalling, xml > > I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. > The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. > Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. > So, i realized that the problem just comes up if i start directly via standalone.sh. > Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. > The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on wildfly 8.1.0.final standalone.sh. > A found another issue about this parameter removing here WFLY-425. > Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. > Best regards! -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:07:29 2014 From: issues at jboss.org (=?UTF-8?Q?victor_fran=C3=A7a_=28JIRA=29?=) Date: Fri, 14 Nov 2014 10:07:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4085) XML Marshalling problems without -jaxpmodule on start scrtipts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] victor fran?a updated WFLY-4085: -------------------------------- Description: I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. So, i realized that the problem just comes up if i start directly via standalone.sh. Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on standalone.sh with wildfly 8.1.0.final. A found another issue about this parameter removing here WFLY-425. Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. Best regards! was: I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. So, i realized that the problem just comes up if i start directly via standalone.sh. Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on wildfly 8.1.0.final standalone.sh. A found another issue about this parameter removing here WFLY-425. Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. Best regards! > XML Marshalling problems without -jaxpmodule on start scrtipts. > --------------------------------------------------------------- > > Key: WFLY-4085 > URL: https://issues.jboss.org/browse/WFLY-4085 > Project: WildFly > Issue Type: Quality Risk > Components: XML Frameworks > Affects Versions: 8.1.0.Final > Reporter: victor fran?a > Assignee: Jason Greene > Labels: jaxb, jaxpmodule, marshalling, xml > > I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. > The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. > Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. > So, i realized that the problem just comes up if i start directly via standalone.sh. > Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. > The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on standalone.sh with wildfly 8.1.0.final. > A found another issue about this parameter removing here WFLY-425. > Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. > Best regards! -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:07:29 2014 From: issues at jboss.org (=?UTF-8?Q?victor_fran=C3=A7a_=28JIRA=29?=) Date: Fri, 14 Nov 2014 10:07:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4085) XML Marshalling problems without -jaxpmodule on start scrtipts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] victor fran?a updated WFLY-4085: -------------------------------- Description: I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. So, i realized that the problem just comes up if i start directly via standalone.sh. Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on standalone.sh with wildfly 8.1.0.final. I found another issue about this parameter removing here WFLY-425. Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. Best regards! was: I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. So, i realized that the problem just comes up if i start directly via standalone.sh. Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on standalone.sh with wildfly 8.1.0.final. A found another issue about this parameter removing here WFLY-425. Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. Best regards! > XML Marshalling problems without -jaxpmodule on start scrtipts. > --------------------------------------------------------------- > > Key: WFLY-4085 > URL: https://issues.jboss.org/browse/WFLY-4085 > Project: WildFly > Issue Type: Quality Risk > Components: XML Frameworks > Affects Versions: 8.1.0.Final > Reporter: victor fran?a > Assignee: Jason Greene > Labels: jaxb, jaxpmodule, marshalling, xml > > I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. > The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. > Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. > So, i realized that the problem just comes up if i start directly via standalone.sh. > Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. > The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on standalone.sh with wildfly 8.1.0.final. > I found another issue about this parameter removing here WFLY-425. > Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. > Best regards! -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:07:30 2014 From: issues at jboss.org (=?UTF-8?Q?victor_fran=C3=A7a_=28JIRA=29?=) Date: Fri, 14 Nov 2014 10:07:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4085) XML Marshalling problems without -jaxpmodule on start scrtipts. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] victor fran?a updated WFLY-4085: -------------------------------- Description: I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. So, i realized that the problem just comes up if i start directly via standalone.sh. Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on standalone.sh with wildfly 8.1.0.final. I found another issue about this removed parameter here WFLY-425. Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. Best regards! was: I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. So, i realized that the problem just comes up if i start directly via standalone.sh. Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on standalone.sh with wildfly 8.1.0.final. I found another issue about this parameter removing here WFLY-425. Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. Best regards! > XML Marshalling problems without -jaxpmodule on start scrtipts. > --------------------------------------------------------------- > > Key: WFLY-4085 > URL: https://issues.jboss.org/browse/WFLY-4085 > Project: WildFly > Issue Type: Quality Risk > Components: XML Frameworks > Affects Versions: 8.1.0.Final > Reporter: victor fran?a > Assignee: Jason Greene > Labels: jaxb, jaxpmodule, marshalling, xml > > I was using a fresh installation of wildfly 8.1.0.final and i faced a very weird situation with a SLSB of mines that uses javax.xml.bind.Marshaller for marshalling an object. > The result of the marshalling process was an incomplete XML. I was sure that there was no problems with the application itself because i could run the code with a main method and get the complete marshalled XML. > Also, i noticed that i could get the right results if I start the Wildfly through my Eclipse Luna. > So, i realized that the problem just comes up if i start directly via standalone.sh. > Then i decided to compare standalone.sh and eclipse's configurations for wildfly initialization. > The answer for the entire problem was that eclipse still adds the parameter -jaxpmodule that it is not present on standalone.sh with wildfly 8.1.0.final. > I found another issue about this removed parameter here WFLY-425. > Well, i could make things works just adding this parameter back to wildfly standalone.sh. But, i have a feeling that something has to be done to make JAXB works without this parameter that was removed. > Best regards! -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:14:29 2014 From: issues at jboss.org (Harald Wellmann (JIRA)) Date: Fri, 14 Nov 2014 10:14:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBASMP-75) serverConfig should accept arbitrary paths In-Reply-To: References: Message-ID: Harald Wellmann created JBASMP-75: ------------------------------------- Summary: serverConfig should accept arbitrary paths Key: JBASMP-75 URL: https://issues.jboss.org/browse/JBASMP-75 Project: JBoss AS Maven Plugins Issue Type: Bug Components: wildfly Environment: wildfly-maven-plugin 1.0.2.Final, WildFly 8.1.0.Final Reporter: Harald Wellmann Assignee: James Perkins The {{serverConfig}} Mojo parameter is described as {quote} The path to the server configuration to use. {quote} However, when specifying a path like {code:xml} src/test/resouces/standalone-test.xml {code} there is an exception {noformat} java.lang.IllegalStateException: JBAS014805: Could not get main file: ... Specified files must be relative to the configuration dir: ... {noformat} This is inconvenient. Users should be able to override the default configurations from a WildFly distribution. E.g. the wildfly-maven-plugin could simply copy the file specified in {{serverConfig}} to {{$JBOSS_HOME/standalone/configuration}}. As a workaround, I now unpack WildFly with the maven-dependency-plugin, copy my configuration with maven-resources-plugin and add the {{jbossHome}} parameter to wildfly-maven-plugin, all of which is rather verbose. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:19:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 10:19:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-112) Long server shut-dow with unresponsive client with opened JNDI Context In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020136#comment-13020136 ] RH Bugzilla Integration commented on WFCORE-112: ------------------------------------------------ Ond?ej Kalman changed the Status of [bug 1139202|https://bugzilla.redhat.com/show_bug.cgi?id=1139202] from ON_QA to VERIFIED > Long server shut-dow with unresponsive client with opened JNDI Context > ---------------------------------------------------------------------- > > Key: WFCORE-112 > URL: https://issues.jboss.org/browse/WFCORE-112 > Project: WildFly Core > Issue Type: Bug > Reporter: Miroslav Novak > Assignee: David Lloyd > Labels: remoting > Attachments: JNDIContext.java, testcase.zip > > > Description of problem: > If client with opened JNDI context is disconnected from network, then clean shutdown (ctrl-c) of server takes 15 minutes. > This scenario takes place, when network connections is lost between JMS clients with JNDI context and server. > Version-Release number of selected component (if applicable): > jboss-remoting-3.3.3.Final-redhat-1.jar > How reproducible: > always > Steps to Reproduce: > 1. Start EAP 6.3.1.CP.CR1 on first machine > 2. Start client which creates JNDI context on second machine (use attached JNDIContext.java) > 3. Disconnect network between client and server > 4. Try to cleanly shutdown EAP 6.3.1.CP.CR1 server (by ctrl-c) > Actual results: > It takes 15 minutes for server to shutdown. > Expected results: > Server should shutdown almost immediately. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:32:29 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 14 Nov 2014 10:32:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-147) Update wildfly-security-manager from 1.0.1.Final to 1.1.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-147: ------------------------------- Fix Version/s: 1.0.0.Alpha13 > Update wildfly-security-manager from 1.0.1.Final to 1.1.0.Final > --------------------------------------------------------------- > > Key: WFCORE-147 > URL: https://issues.jboss.org/browse/WFCORE-147 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:39:29 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 14 Nov 2014 10:39:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3932) Enable security manager via JBoss Modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFLY-3932: ------------------------------ Description: In WildFly Core the security manager can be enabled via the {{-secmgr}} argument or setting the {{SECMGR=true}} environment variable. In order for this change to work correctly the {{WildFlySecurityManager.install()}} needs to be disabled. Also -all- standalone, process-controller and host-controller modules that declare a dependency on {{org.wildfly.security.manager}} need to export the services. The security manager test suite configuration needs to be updated to use the {{-secmgr}} argument rather than using {{-Dsecurity.manager}} to transform the profile (though the same system property should probably be reused to add the argument, like we had originally done). Test suite configuration needs to be updated to *always* enable the security manager subsystem, even if the security manager is disabled. This will cause the permissions to still be associated with deployments (though they will not be used unless -secmgr was passed to the startup script). was: In WildFly Core the security manager can be enabled via the {{-secmgr}} argument or setting the {{SECMGR=true}} environment variable. In order for this change to work correctly the {{WildFlySecurityManager.install()}} needs to be disabled. Also -all- standalone, process-controller and host-controller modules that declare a dependency on {{org.wildfly.security.manager}} need to export the services. Tests need to be updated to use the {{-secmgr}} argument rather than {{-Djava.security.manager}}. > Enable security manager via JBoss Modules > ----------------------------------------- > > Key: WFLY-3932 > URL: https://issues.jboss.org/browse/WFLY-3932 > Project: WildFly > Issue Type: Feature Request > Components: Security Manager > Reporter: James Perkins > Assignee: James Perkins > > In WildFly Core the security manager can be enabled via the {{-secmgr}} argument or setting the {{SECMGR=true}} environment variable. In order for this change to work correctly the {{WildFlySecurityManager.install()}} needs to be disabled. > Also -all- standalone, process-controller and host-controller modules that declare a dependency on {{org.wildfly.security.manager}} need to export the services. > The security manager test suite configuration needs to be updated to use the {{-secmgr}} argument rather than using {{-Dsecurity.manager}} to transform the profile (though the same system property should probably be reused to add the argument, like we had originally done). > Test suite configuration needs to be updated to *always* enable the security manager subsystem, even if the security manager is disabled. This will cause the permissions to still be associated with deployments (though they will not be used unless -secmgr was passed to the startup script). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:42:29 2014 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Fri, 14 Nov 2014 10:42:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3783) Upgrade Hibernate ORM to 4.3.7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020149#comment-13020149 ] Scott Marlow commented on WFLY-3783: ------------------------------------ the upgrade is done but the desire HHH-9337 jira is not yet fixed. Closing since an upgrade already occurred against this jira. > Upgrade Hibernate ORM to 4.3.7 > ------------------------------ > > Key: WFLY-3783 > URL: https://issues.jboss.org/browse/WFLY-3783 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Paul Ferraro > Assignee: Scott Marlow > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 10:59:31 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 14 Nov 2014 10:59:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-218) wildfly web management console hangs during deploy from cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020158#comment-13020158 ] Brian Stansberry commented on WFCORE-218: ----------------------------------------- The thread dump shows 2 console request threads blocking waiting for the exclusive controller lock that is held by the thread executing the deployment op. The console request threads are asking for the exclusive lock so they can execute a 2-phase domain wide operation. All such ops get the exclusive lock so they can prevent domain topology changes during execution. There are two ways I want to improve this: 1) I believe when the console sends a composite operation, it is getting routed into the 2-phase domain wide operation path more often than is necessary. Improving this needs to be done carefully, but should be a relatively straightforward change and probably will have the biggest impact, as most of the CRUD screens in the console don't need to invoke ops that involve more than the domain controller. 2) Look into having a separate lock for the domain topology, and not using the exclusive controller lock to guard it. That requires care though, as now there will be two separate locks involved in operation execution. We need to be certain that all code paths always acquire them in the same order or we'll be vulnerable to deadlocks. I believe the correct order should be 1) topology lock 2) controller lock. There are relatively few points where a topology lock would be needed, and I believe they are all at the outer edge of operation execution. So it's much simpler to control those points and ensure they always get topology before doing anything that could need the controller lock. This second step will be more important once the feature discussed at http://lists.jboss.org/pipermail/wildfly-dev/2014-October/003241.html comes in, as that will result in numerous read operations that truly need the domain topology lock. > wildfly web management console hangs during deploy from cli > ----------------------------------------------------------- > > Key: WFCORE-218 > URL: https://issues.jboss.org/browse/WFCORE-218 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha1 > Reporter: Ian Kent > Assignee: Brian Stansberry > Attachments: threaddump-1415735255304.tdump > > > We are running wildfly in domain mode with the following configuration. > host A running domain controlller > host B running host controller with one app sever > host C running host controller with one app server > host D running host controller with one app server > When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 11:02:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 14 Nov 2014 11:02:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-251) Avoiding unnecessary 2-phase execution of composite operations in a managed domain In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-251: --------------------------------------- Summary: Avoiding unnecessary 2-phase execution of composite operations in a managed domain Key: WFCORE-251 URL: https://issues.jboss.org/browse/WFCORE-251 Project: WildFly Core Issue Type: Sub-task Components: Domain Management Affects Versions: 1.0.0.Alpha12 Reporter: Brian Stansberry When the console sends a composite operation, it is getting routed into the 2-phase domain wide operation path more often than is necessary, resulting in requests for the exclusive controller lock for read-only ops that could be executed on the local process without needing the lock. Improving this needs to be done carefully, but should be a relatively straightforward change and probably will have the biggest impact on the parent issue, as most of the CRUD screens in the console don't need to invoke ops that involve more than the domain controller. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 11:05:29 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Fri, 14 Nov 2014 11:05:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4086) If a ManagedExecutorService's Runnable throws an exception, it should not be eaten (but it's stacktrace should be shown in teh console) by default In-Reply-To: References: Message-ID: Geoffrey De Smet created WFLY-4086: -------------------------------------- Summary: If a ManagedExecutorService's Runnable throws an exception, it should not be eaten (but it's stacktrace should be shown in teh console) by default Key: WFLY-4086 URL: https://issues.jboss.org/browse/WFLY-4086 Project: WildFly Issue Type: Enhancement Affects Versions: 8.1.0.Final Reporter: Geoffrey De Smet Assignee: Jason Greene To reproduce: {code} @Resource(name = "DefaultManagedExecutorService") ManagedExecutorService executor; public String myRestMethod() { executor.submit(new SolverCallable()); return "Submitted."; } private class SolverCallable implements Runnable { public void run() { throw new IllegalStateException("Tweety bird: Please Sylvester, don't eat me!"); } } {code} Poor tweety bird's plea (nor the stacktrace) doesn't show up in the WildFly console of a vanilla installation. This led me to believe I had no error. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 11:06:29 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Fri, 14 Nov 2014 11:06:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4086) If a ManagedExecutorService's Runnable throws an exception, it should not be eaten (but it's stacktrace should be shown in the console) by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated WFLY-4086: ----------------------------------- Summary: If a ManagedExecutorService's Runnable throws an exception, it should not be eaten (but it's stacktrace should be shown in the console) by default (was: If a ManagedExecutorService's Runnable throws an exception, it should not be eaten (but it's stacktrace should be shown in teh console) by default) > If a ManagedExecutorService's Runnable throws an exception, it should not be eaten (but it's stacktrace should be shown in the console) by default > -------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4086 > URL: https://issues.jboss.org/browse/WFLY-4086 > Project: WildFly > Issue Type: Enhancement > Affects Versions: 8.1.0.Final > Reporter: Geoffrey De Smet > Assignee: Jason Greene > > To reproduce: > {code} > @Resource(name = "DefaultManagedExecutorService") > ManagedExecutorService executor; > public String myRestMethod() { > executor.submit(new SolverCallable()); > return "Submitted."; > } > private class SolverCallable implements Runnable { > public void run() { > throw new IllegalStateException("Tweety bird: Please Sylvester, don't eat me!"); > } > } > {code} > Poor tweety bird's plea (nor the stacktrace) doesn't show up in the WildFly console of a vanilla installation. > This led me to believe I had no error. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 11:07:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 14 Nov 2014 11:07:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-252) Guard domain topology changes with separate locks from the controller lock In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-252: --------------------------------------- Summary: Guard domain topology changes with separate locks from the controller lock Key: WFCORE-252 URL: https://issues.jboss.org/browse/WFCORE-252 Project: WildFly Core Issue Type: Sub-task Components: Domain Management Affects Versions: 1.0.0.Alpha12 Reporter: Brian Stansberry Look into having a separate lock for the domain topology, and not using the exclusive controller lock to guard it. This requires great care though, as now there will be two separate locks involved in operation execution. We need to be certain that all code paths always acquire them in the same order or we'll be vulnerable to deadlocks. I believe the correct order should be 1) topology lock 2) controller lock. There are relatively few points where a topology lock would be needed, and I believe they are all at the outer edge of operation execution. So it's much simpler to control those points and ensure they always get topology before doing anything that could need the controller lock. Note it's possible 3 locks will be involved, one for host topology, one for server, and then the controller lock. Locking order needs to be thought about on a domain-wide basis, not just within a single process! This task will be more important once the feature discussed at http://lists.jboss.org/pipermail/wildfly-dev/2014-October/003241.html comes in, as that will result in numerous read operations that truly need the domain topology lock. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 11:12:31 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 14 Nov 2014 11:12:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-218) wildfly web management console hangs during deploy from cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020177#comment-13020177 ] Brian Stansberry commented on WFCORE-218: ----------------------------------------- A third possibility is to not do 2) above but instead focus on discriminating 2-phase ops that are purely reads from those that may involve writes. Evaluate to what degree topology stability is important to different cases, and see if the need for acquiring a lock to ensure it can be dropped in important cases. The biggest issue is if a 2-phase read is executing but one of the target processes leaves the domain, that needs to be handled in a reasonable fashion. This requirement already applies in the case of a target process crashing though. > wildfly web management console hangs during deploy from cli > ----------------------------------------------------------- > > Key: WFCORE-218 > URL: https://issues.jboss.org/browse/WFCORE-218 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha1 > Reporter: Ian Kent > Assignee: Brian Stansberry > Attachments: threaddump-1415735255304.tdump > > > We are running wildfly in domain mode with the following configuration. > host A running domain controlller > host B running host controller with one app sever > host C running host controller with one app server > host D running host controller with one app server > When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 12:56:29 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 14 Nov 2014 12:56:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020239#comment-13020239 ] Emmanuel Hugonnet commented on WFCORE-242: ------------------------------------------ [Host Controller] 18:53:49,120 INFO [org.jboss.as.deployment] (management-handler-thread - 2) ServerGroupDeploymentUndeployHandler is undeploying something { [Host Controller] "operation" => "undeploy", [Host Controller] "address" => [ [Host Controller] ("server-group" => "main-server-group"), [Host Controller] ("deployment" => "wildfly-ejb-in-war.war") [Host Controller] ], [Host Controller] "operation-headers" => { [Host Controller] "caller-type" => "user", [Host Controller] "access-mechanism" => "NATIVE", [Host Controller] "domain-uuid" => "79e6a653-cf73-4d4f-a9b7-df0a83795da3" [Host Controller] } [Host Controller] } [Host Controller] 18:53:49,125 INFO [org.jboss.as.deployment] (management-handler-thread - 2) ServerGroupDeploymentRemoveHandler is removing something { [Host Controller] "operation" => "remove", [Host Controller] "address" => [ [Host Controller] ("server-group" => "main-server-group"), [Host Controller] ("deployment" => "wildfly-ejb-in-war.war") [Host Controller] ], [Host Controller] "operation-headers" => { [Host Controller] "caller-type" => "user", [Host Controller] "access-mechanism" => "NATIVE", [Host Controller] "domain-uuid" => "79e6a653-cf73-4d4f-a9b7-df0a83795da3" [Host Controller] } [Host Controller] } [Host Controller] 18:53:49,136 INFO [org.jboss.as.deployment] (management-handler-thread - 2) ServerGroupDeploymentAddHandler is adding something { [Host Controller] "operation" => "add", [Host Controller] "address" => [ [Host Controller] ("server-group" => "main-server-group"), [Host Controller] ("deployment" => "wildfly-ejb-in-war.war") [Host Controller] ], [Host Controller] "operation-headers" => { [Host Controller] "caller-type" => "user", [Host Controller] "access-mechanism" => "NATIVE", [Host Controller] "domain-uuid" => "79e6a653-cf73-4d4f-a9b7-df0a83795da3" [Host Controller] } [Host Controller] } [Host Controller] 18:53:49,143 INFO [org.jboss.as.deployment] (management-handler-thread - 2) ServerGroupDeploymentDeployHandler is enabling something { [Host Controller] "operation" => "deploy", [Host Controller] "address" => [ [Host Controller] ("server-group" => "main-server-group"), [Host Controller] ("deployment" => "wildfly-ejb-in-war.war") [Host Controller] ], [Host Controller] "operation-headers" => { [Host Controller] "caller-type" => "user", [Host Controller] "access-mechanism" => "NATIVE", [Host Controller] "domain-uuid" => "79e6a653-cf73-4d4f-a9b7-df0a83795da3" [Host Controller] } [Host Controller] } [Server:server-one] 18:53:49,252 INFO [org.jboss.as.server] (ServerService Thread Pool -- 20) DeploymentUndeployHandler is undeploying something { [Server:server-one] "operation" => "undeploy", [Server:server-one] "address" => [("deployment" => "wildfly-ejb-in-war.war")], [Server:server-one] "operation-headers" => {} [Server:server-one] } [Server:server-two] 18:53:49,263 INFO [org.jboss.as.server] (ServerService Thread Pool -- 12) DeploymentUndeployHandler is undeploying something { [Server:server-two] "operation" => "undeploy", [Server:server-two] "address" => [("deployment" => "wildfly-ejb-in-war.war")], [Server:server-two] "operation-headers" => {} [Server:server-two] } [Server:server-one] 18:53:49,267 INFO [org.jboss.as.server] (ServerService Thread Pool -- 20) DeploymentAddHandler is adding something { [Server:server-one] "operation" => "add", [Server:server-one] "address" => [("deployment" => "wildfly-ejb-in-war.war")], [Server:server-one] "operation-headers" => {}, [Server:server-one] "runtime-name" => "wildfly-ejb-in-war.war", [Server:server-one] "content" => [{"hash" => bytes { [Server:server-one] 0x5e, 0x4b, 0x77, 0x2f, 0xb7, 0xc3, 0x95, 0xc3, [Server:server-one] 0xc3, 0x00, 0xda, 0xd6, 0xe9, 0x3e, 0x3d, 0x8c, [Server:server-one] 0x7e, 0xcd, 0xea, 0x20 [Server:server-one] }}] [Server:server-one] } [Server:server-one] 18:53:49,270 INFO [org.jboss.as.server] (ServerService Thread Pool -- 20) DeploymentDeployHandler is enabling something { [Server:server-one] "operation" => "deploy", [Server:server-one] "address" => [("deployment" => "wildfly-ejb-in-war.war")], [Server:server-one] "operation-headers" => {} [Server:server-one] } [Server:server-one] 18:53:49,280 INFO [org.jboss.as.server] (ServerService Thread Pool -- 20) DeploymentRemoveHandler is removing something { [Server:server-one] "operation" => "remove", [Server:server-one] "address" => [("deployment" => "wildfly-ejb-in-war.war")], [Server:server-one] "operation-headers" => {} [Server:server-one] } [Server:server-two] 18:53:49,284 INFO [org.jboss.as.server] (ServerService Thread Pool -- 12) DeploymentAddHandler is adding something { [Server:server-two] "operation" => "add", [Server:server-two] "address" => [("deployment" => "wildfly-ejb-in-war.war")], [Server:server-two] "operation-headers" => {}, [Server:server-two] "runtime-name" => "wildfly-ejb-in-war.war", [Server:server-two] "content" => [{"hash" => bytes { [Server:server-two] 0x5e, 0x4b, 0x77, 0x2f, 0xb7, 0xc3, 0x95, 0xc3, [Server:server-two] 0xc3, 0x00, 0xda, 0xd6, 0xe9, 0x3e, 0x3d, 0x8c, [Server:server-two] 0x7e, 0xcd, 0xea, 0x20 [Server:server-two] }}] [Server:server-two] } [Server:server-two] 18:53:49,286 INFO [org.jboss.as.server] (ServerService Thread Pool -- 12) DeploymentDeployHandler is enabling something { [Server:server-two] "operation" => "deploy", [Server:server-two] "address" => [("deployment" => "wildfly-ejb-in-war.war")], [Server:server-two] "operation-headers" => {} [Server:server-two] } [Server:server-one] 18:53:49,299 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0022: Unregistered web context: /wildfly-ejb-in-war [Server:server-two] 18:53:49,303 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0022: Unregistered web context: /wildfly-ejb-in-war [Server:server-two] 18:53:49,293 INFO [org.jboss.as.server] (ServerService Thread Pool -- 12) DeploymentRemoveHandler is removing something { [Server:server-two] "operation" => "remove", [Server:server-two] "address" => [("deployment" => "wildfly-ejb-in-war.war")], [Server:server-two] "operation-headers" => {} [Server:server-two] } > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 12:58:29 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 14 Nov 2014 12:58:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020241#comment-13020241 ] Emmanuel Hugonnet commented on WFCORE-242: ------------------------------------------ So it looks like the commands on the servers are not runned in the expected order. > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 13:30:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 14 Nov 2014 13:30:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-65) Filesystem deployment scanner deployment failure removes other scanners ' deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-65: -------------------------------------- Assignee: (was: Brian Stansberry) > Filesystem deployment scanner deployment failure removes other scanners ' deployments > ------------------------------------------------------------------------------------- > > Key: WFCORE-65 > URL: https://issues.jboss.org/browse/WFCORE-65 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha5 > Reporter: Emmanuel Hugonnet > > There is no way to associate a deployment to a specific scanner thus if one deployment fails for a scanner during startup all deployments not persistent will be removed -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 13:31:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 14 Nov 2014 13:31:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-98) Remoting is using the wrong protocol names In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-98: -------------------------------------- Assignee: (was: Brian Stansberry) > Remoting is using the wrong protocol names > ------------------------------------------ > > Key: WFCORE-98 > URL: https://issues.jboss.org/browse/WFCORE-98 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting > Reporter: David Lloyd > > The Remoting protocol names are presently: > * remoting > * http-remoting > * https-remoting > They should be: > * remote > * remote+http > * remote+https > respectively. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 13:31:30 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 14 Nov 2014 13:31:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-85) Remove non socket-binding attributes from management interfaces In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-85: -------------------------------------- Assignee: (was: Brian Stansberry) > Remove non socket-binding attributes from management interfaces > --------------------------------------------------------------- > > Key: WFCORE-85 > URL: https://issues.jboss.org/browse/WFCORE-85 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Tomaz Cerar > > Remove HttpManagementResourceDefinition#http-port, https-port, interface, secure-interface > as this ware replaced by socket-binding and secure-socket-binding around 7.0 time frame. > Given that it only adds complexity and no real added value they should be removed as disscussed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 13:50:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 13:50:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-98) Remoting is using the wrong protocol names In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reassigned WFCORE-98: -------------------------------------- Assignee: Darran Lofthouse > Remoting is using the wrong protocol names > ------------------------------------------ > > Key: WFCORE-98 > URL: https://issues.jboss.org/browse/WFCORE-98 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting > Reporter: David Lloyd > Assignee: Darran Lofthouse > > The Remoting protocol names are presently: > * remoting > * http-remoting > * https-remoting > They should be: > * remote > * remote+http > * remote+https > respectively. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 13:50:29 2014 From: issues at jboss.org (Patrick Thomas (JIRA)) Date: Fri, 14 Nov 2014 13:50:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-649) Complex Dependencies Cause In-Reply-To: References: Message-ID: Patrick Thomas created DROOLS-649: ------------------------------------- Summary: Complex Dependencies Cause Key: DROOLS-649 URL: https://issues.jboss.org/browse/DROOLS-649 Project: Drools Issue Type: Bug Affects Versions: 6.1.0.Final Environment: Drools 6.1.0, WildFly 8.1, JDK 1.7 Reporter: Patrick Thomas Assignee: Mark Proctor When I add a dependency to my project that has other dependencies, KIE fills up my log file with multiple warnings and errors. See the forum reference for a sampling of messages I am receiving. One single reference filled my log file with 8MB of messages. KIE appears to attempt to load every dependency of my dependency, and every dependency of those dependencies, and so on. The system becomes unusable for a while. After the scan is done, my Type drop down in the Data Modeler is filled with so many classes that it is difficult to find what I need. The last problem (not mentioned in the forum) is that I can't shut down WildFly. I seem to get stuck in an endless loop with the following message being displayed repeatedly: 13:41:55,522 WARN [org.jbpm.executor.impl.ExecutorRunnable] (pool-14-thread-1) Error while executing jobs due to {}null It's possible that WildFly would eventually shut down, but I end up stopping the task forcibly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:01:29 2014 From: issues at jboss.org (Edson Tirelli (JIRA)) Date: Fri, 14 Nov 2014 14:01:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-647) memory leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edson Tirelli updated DROOLS-647: --------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > memory leak > ----------- > > Key: DROOLS-647 > URL: https://issues.jboss.org/browse/DROOLS-647 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Reporter: Dawna Floyd > Assignee: Mario Fusco > Attachments: DROOL_TEST.zip > > > references to fact handles not being removed when objects are removed from memory. Converted our application from 5.0.1 to 6.1_Final and encountered memory leaks in the drools processing. Found references to defect 498 and checked out the 6.1.1 code based and built the source (the download package doesn't seem to have these fixes). The majority of leaks were corrected with this code line, however there still remains a memory leak when we run our defined rules. Even though a rule never fires, it's evaluation seems to hold onto beta memory forever and the test application will eventually run out of memory. I can provide a test program that highlights the leak. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:19:29 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 14 Nov 2014 14:19:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBASMP-75) serverConfig should accept arbitrary paths In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBASMP-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed JBASMP-75. ------------------------------- Resolution: Rejected The server requires the configuration to be in the configuration directory. It's a limitation on the server not the maven plugin. If you specify the {{jboss.server.config.dir}} that points to {{src/test/resources}} should work though. One thing to note about that approach is a {{logging.properties}} would likely be written there as well. > serverConfig should accept arbitrary paths > ------------------------------------------ > > Key: JBASMP-75 > URL: https://issues.jboss.org/browse/JBASMP-75 > Project: JBoss AS Maven Plugins > Issue Type: Bug > Components: wildfly > Environment: wildfly-maven-plugin 1.0.2.Final, WildFly 8.1.0.Final > Reporter: Harald Wellmann > Assignee: James Perkins > > The {{serverConfig}} Mojo parameter is described as > {quote} > The path to the server configuration to use. > {quote} > However, when specifying a path like > {code:xml} > src/test/resouces/standalone-test.xml > {code} > there is an exception > {noformat} > java.lang.IllegalStateException: JBAS014805: Could not get main file: ... Specified files must be relative to the configuration dir: ... > {noformat} > This is inconvenient. Users should be able to override the default configurations from a WildFly distribution. E.g. the wildfly-maven-plugin could simply copy the file specified in {{serverConfig}} to {{$JBOSS_HOME/standalone/configuration}}. > As a workaround, I now unpack WildFly with the maven-dependency-plugin, copy my configuration with maven-resources-plugin and add the {{jbossHome}} parameter to wildfly-maven-plugin, all of which is rather verbose. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:28:29 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 14 Nov 2014 14:28:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020263#comment-13020263 ] Brian Stansberry commented on WFCORE-242: ----------------------------------------- The way this works is after the HC executes the normal operation steps (you've logged some of that), a step that executes ServerOperationsResolverHandler is executed. It calls ServerOperationResolver, whose job is to translate the HC-level ops into a set of ops to invoke on the servers.* So the first place to look is there, to confirm it is producing the correct sequence of operations to execute on the servers. HostControllerExecutionSupport.Factory and HostControllerExecutionSupport.MultiStepOpExecutionSupport are good places to look, as they deal with composites. * ServerOperationsResolverHandler adds the op ModelNodes as data on the response, making it available to whatever HC is controlling rollout of the overall op across the domain. In this case that would be the master HC. The controlling HC then tells the servers to execute. It's possible the problem is there, but it's better to start with ServerOperationsResolverHandler. > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:37:29 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 14 Nov 2014 14:37:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-253) Remoting subsystem sasl-protocol and server-name should support expressions In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-253: --------------------------------------- Summary: Remoting subsystem sasl-protocol and server-name should support expressions Key: WFCORE-253 URL: https://issues.jboss.org/browse/WFCORE-253 Project: WildFly Core Issue Type: Bug Components: Remoting Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha13 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:44:29 2014 From: issues at jboss.org (Mark Proctor (JIRA)) Date: Fri, 14 Nov 2014 14:44:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-650) Sequential Phreak is broken In-Reply-To: References: Message-ID: Mark Proctor created DROOLS-650: ----------------------------------- Summary: Sequential Phreak is broken Key: DROOLS-650 URL: https://issues.jboss.org/browse/DROOLS-650 Project: Drools Issue Type: Feature Request Affects Versions: 6.2.0.CR2, 6.1.0.Final, 6.0.1.Final Reporter: Mark Proctor Assignee: Mark Proctor -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:44:29 2014 From: issues at jboss.org (Mark Proctor (JIRA)) Date: Fri, 14 Nov 2014 14:44:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-650) Sequential Phreak is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Proctor updated DROOLS-650: -------------------------------- Fix Version/s: 6.2.0.CR3 > Sequential Phreak is broken > ---------------------------- > > Key: DROOLS-650 > URL: https://issues.jboss.org/browse/DROOLS-650 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.0.1.Final, 6.1.0.Final, 6.2.0.CR2 > Reporter: Mark Proctor > Assignee: Mark Proctor > Fix For: 6.2.0.CR3 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:46:30 2014 From: issues at jboss.org (J Sanz A (JIRA)) Date: Fri, 14 Nov 2014 14:46:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AS7-5043) Filtering of logging messages works incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020274#comment-13020274 ] J Sanz A commented on AS7-5043: ------------------------------- jboss 7.2.0, the following still fail... only one is accepted ... how to include many "match"? and it is very interesting the use of """ into the xml file instead of the normal symbol " > Filtering of logging messages works incorrectly > ----------------------------------------------- > > Key: AS7-5043 > URL: https://issues.jboss.org/browse/AS7-5043 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.1.1.Final > Reporter: Oleg Nitz > Assignee: James Perkins > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > In standalone.xml I'm trying to filter out wrong error messages: > > > > > > > > > > But this doesn't work, and under debugger I see that the configuration got parsed as > "filter" => {"all" => {"not" => {"match" => "JBAS011806: Channel end notification received, closing channel Channel ID"}}}, > Looks like due to the use of maps for storing the parsing results the first "not" filter got overwritten by the second "not" filter. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:46:31 2014 From: issues at jboss.org (J Sanz A (JIRA)) Date: Fri, 14 Nov 2014 14:46:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AS7-5043) Filtering of logging messages works incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020274#comment-13020274 ] J Sanz A edited comment on AS7-5043 at 11/14/14 2:46 PM: --------------------------------------------------------- jboss 7.2.0, the following still fails... only one is accepted ...how to include many "match"? and it is very interesting the use of """ into the xml file instead of the normal symbol " was (Author: eskuai): jboss 7.2.0, the following still fail... only one is accepted ... how to include many "match"? and it is very interesting the use of """ into the xml file instead of the normal symbol " > Filtering of logging messages works incorrectly > ----------------------------------------------- > > Key: AS7-5043 > URL: https://issues.jboss.org/browse/AS7-5043 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.1.1.Final > Reporter: Oleg Nitz > Assignee: James Perkins > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > In standalone.xml I'm trying to filter out wrong error messages: > > > > > > > > > > But this doesn't work, and under debugger I see that the configuration got parsed as > "filter" => {"all" => {"not" => {"match" => "JBAS011806: Channel end notification received, closing channel Channel ID"}}}, > Looks like due to the use of maps for storing the parsing results the first "not" filter got overwritten by the second "not" filter. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:47:30 2014 From: issues at jboss.org (J Sanz A (JIRA)) Date: Fri, 14 Nov 2014 14:47:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AS7-5043) Filtering of logging messages works incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020274#comment-13020274 ] J Sanz A edited comment on AS7-5043 at 11/14/14 2:46 PM: --------------------------------------------------------- jboss 7.2.0, the following still fails... only one is accepted ...how to include many "match"? and it is very interesting the use of """ into the xml file instead of the normal symbol " was (Author: eskuai): jboss 7.2.0, the following still fails... only one is accepted ...how to include many "match"? and it is very interesting the use of """ into the xml file instead of the normal symbol " > Filtering of logging messages works incorrectly > ----------------------------------------------- > > Key: AS7-5043 > URL: https://issues.jboss.org/browse/AS7-5043 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.1.1.Final > Reporter: Oleg Nitz > Assignee: James Perkins > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > In standalone.xml I'm trying to filter out wrong error messages: > > > > > > > > > > But this doesn't work, and under debugger I see that the configuration got parsed as > "filter" => {"all" => {"not" => {"match" => "JBAS011806: Channel end notification received, closing channel Channel ID"}}}, > Looks like due to the use of maps for storing the parsing results the first "not" filter got overwritten by the second "not" filter. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:47:31 2014 From: issues at jboss.org (J Sanz A (JIRA)) Date: Fri, 14 Nov 2014 14:47:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AS7-5043) Filtering of logging messages works incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020274#comment-13020274 ] J Sanz A edited comment on AS7-5043 at 11/14/14 2:47 PM: --------------------------------------------------------- jboss 7.2.0, the following still fails... only one is accepted ...how to include many "match"? and it is very interesting the use of """ into the xml file instead of the normal symbol " was (Author: eskuai): jboss 7.2.0, the following still fails... only one is accepted ...how to include many "match"? and it is very interesting the use of """ into the xml file instead of the normal symbol " > Filtering of logging messages works incorrectly > ----------------------------------------------- > > Key: AS7-5043 > URL: https://issues.jboss.org/browse/AS7-5043 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.1.1.Final > Reporter: Oleg Nitz > Assignee: James Perkins > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > In standalone.xml I'm trying to filter out wrong error messages: > > > > > > > > > > But this doesn't work, and under debugger I see that the configuration got parsed as > "filter" => {"all" => {"not" => {"match" => "JBAS011806: Channel end notification received, closing channel Channel ID"}}}, > Looks like due to the use of maps for storing the parsing results the first "not" filter got overwritten by the second "not" filter. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:48:30 2014 From: issues at jboss.org (J Sanz A (JIRA)) Date: Fri, 14 Nov 2014 14:48:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AS7-5043) Filtering of logging messages works incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020274#comment-13020274 ] J Sanz A edited comment on AS7-5043 at 11/14/14 2:47 PM: --------------------------------------------------------- jboss 7.2.0, the following still fails... only one is accepted ...how to include many "match"? and it is very interesting the use of """ into the xml file instead of the normal symbol " was (Author: eskuai): jboss 7.2.0, the following still fails... only one is accepted ...how to include many "match"? and it is very interesting the use of """ into the xml file instead of the normal symbol " > Filtering of logging messages works incorrectly > ----------------------------------------------- > > Key: AS7-5043 > URL: https://issues.jboss.org/browse/AS7-5043 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.1.1.Final > Reporter: Oleg Nitz > Assignee: James Perkins > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > In standalone.xml I'm trying to filter out wrong error messages: > > > > > > > > > > But this doesn't work, and under debugger I see that the configuration got parsed as > "filter" => {"all" => {"not" => {"match" => "JBAS011806: Channel end notification received, closing channel Channel ID"}}}, > Looks like due to the use of maps for storing the parsing results the first "not" filter got overwritten by the second "not" filter. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:48:31 2014 From: issues at jboss.org (J Sanz A (JIRA)) Date: Fri, 14 Nov 2014 14:48:31 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AS7-5043) Filtering of logging messages works incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020274#comment-13020274 ] J Sanz A edited comment on AS7-5043 at 11/14/14 2:48 PM: --------------------------------------------------------- jboss 7.2.0, the following still fails... only one is accepted ...how to include many "match"? and it is very interesting the use of "&_quot;" into the xml file instead of the normal symbol " was (Author: eskuai): jboss 7.2.0, the following still fails... only one is accepted ...how to include many "match"? and it is very interesting the use of """ into the xml file instead of the normal symbol " > Filtering of logging messages works incorrectly > ----------------------------------------------- > > Key: AS7-5043 > URL: https://issues.jboss.org/browse/AS7-5043 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.1.1.Final > Reporter: Oleg Nitz > Assignee: James Perkins > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > In standalone.xml I'm trying to filter out wrong error messages: > > > > > > > > > > But this doesn't work, and under debugger I see that the configuration got parsed as > "filter" => {"all" => {"not" => {"match" => "JBAS011806: Channel end notification received, closing channel Channel ID"}}}, > Looks like due to the use of maps for storing the parsing results the first "not" filter got overwritten by the second "not" filter. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 14:49:30 2014 From: issues at jboss.org (J Sanz A (JIRA)) Date: Fri, 14 Nov 2014 14:49:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AS7-5043) Filtering of logging messages works incorrectly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-5043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020274#comment-13020274 ] J Sanz A edited comment on AS7-5043 at 11/14/14 2:48 PM: --------------------------------------------------------- jboss 7.2.0, the following still fails... only one is accepted ...how to include many "match"? and it is very interesting the use of "&_quot;" into the xml file instead of the normal symbol " was (Author: eskuai): jboss 7.2.0, the following still fails... only one is accepted ...how to include many "match"? and it is very interesting the use of "&_quot;" into the xml file instead of the normal symbol " > Filtering of logging messages works incorrectly > ----------------------------------------------- > > Key: AS7-5043 > URL: https://issues.jboss.org/browse/AS7-5043 > Project: Application Server 7 > Issue Type: Bug > Components: Logging > Affects Versions: 7.1.1.Final > Reporter: Oleg Nitz > Assignee: James Perkins > Fix For: EAP 6.1.0.Alpha (7.2.0.Final) > > > In standalone.xml I'm trying to filter out wrong error messages: > > > > > > > > > > But this doesn't work, and under debugger I see that the configuration got parsed as > "filter" => {"all" => {"not" => {"match" => "JBAS011806: Channel end notification received, closing channel Channel ID"}}}, > Looks like due to the use of maps for storing the parsing results the first "not" filter got overwritten by the second "not" filter. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 15:03:29 2014 From: issues at jboss.org (Roger Lefebvre (JIRA)) Date: Fri, 14 Nov 2014 15:03:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-645) Accumulate returned fact causing NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020280#comment-13020280 ] Roger Lefebvre commented on DROOLS-645: --------------------------------------- I tried the provided test with my accumulator and status message class. The results were the same. Must be a state issue. Regardless, given the cleaner solution you suggested, I am going to let this one rest. Thanks for your assistance Mario. > Accumulate returned fact causing NPE > ------------------------------------ > > Key: DROOLS-645 > URL: https://issues.jboss.org/browse/DROOLS-645 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta2 > Environment: Mac OSX (maverick) > Reporter: Roger Lefebvre > Assignee: Mario Fusco > Attachments: RetryOldestCallTimeAccumulateFunction.java, RetryOldestCallTimeAccumulateFunction.java > > > The issue is discussed in https://groups.google.com/forum/?hl=en-GB#!topic/drools-usage/aZU5mXSgHMI. > Here is the gist of it.... > I changed the accumulator to the following and it worked: > accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), $message:oldestRetry( $sm )) > The previous approach was this: > $message:StatusMessage() from accumulate($sm:StatusMessage(campaignName==$campaign.campaignName, status==ManagerCallState.CALLER_FAILURE, attempts<3, sent==true), oldestRetry( $sm )) > which I thought was the correct or acceptable syntax option. Is there something I have overlooked in the second one ("from"??). It does give me a StatusMessage object but it lacks the underlying properties to allow the subsequent modify to work. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 16:13:29 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 14 Nov 2014 16:13:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3954) Upgrade WildFly Core to 1.0.0.Alpha10 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd resolved WFLY-3954. ------------------------------- Resolution: Done Was apparently done some time ago. > Upgrade WildFly Core to 1.0.0.Alpha10 > ------------------------------------- > > Key: WFLY-3954 > URL: https://issues.jboss.org/browse/WFLY-3954 > Project: WildFly > Issue Type: Component Upgrade Subtask > Reporter: David Lloyd > Assignee: Jason Greene > Fix For: 9.0.0.Beta1 > > > Dependent issue for all issues which need a WFCORE upgrade to continue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 16:13:30 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 14 Nov 2014 16:13:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3956) Parent Issue for WildFly Core upgrades In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd closed WFLY-3956. ----------------------------- Resolution: Rejected Unsurprisingly, this isn't working. > Parent Issue for WildFly Core upgrades > -------------------------------------- > > Key: WFLY-3956 > URL: https://issues.jboss.org/browse/WFLY-3956 > Project: WildFly > Issue Type: Component Upgrade > Reporter: David Lloyd > > This is a placeholder issue which is the enclosing issue for all Core upgrades. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 17:34:29 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 14 Nov 2014 17:34:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4025) Log Viewer [Download] does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFLY-4025. ------------------------------- Fix Version/s: 9.0.0.Beta1 Resolution: Done The console has this fixed in upstream 9. 8.x will not see the feature working. > Log Viewer [Download] does not work > ----------------------------------- > > Key: WFLY-4025 > URL: https://issues.jboss.org/browse/WFLY-4025 > Project: WildFly > Issue Type: Bug > Components: Logging, Web Console > Affects Versions: 8.1.0.Final > Reporter: Robert Smith > Assignee: James Perkins > Fix For: 9.0.0.Beta1 > > > We are running a domain mode configuration using Wildfly 8.1.0.Final 'Kenny'. The Log Viewer allows us to [View] logs but the download button does nothing. No error is reported in the server.log when pressing the button and the log file is not downloaded. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 17:36:29 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 14 Nov 2014 17:36:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-254) logging-profiles doesn't work with Apache Common Logging In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins moved WFLY-3952 to WFCORE-254: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-254 (was: WFLY-3952) Affects Version/s: (was: 8.1.0.Final) (was: 9.0.0.Alpha1) Component/s: Logging (was: Logging) > logging-profiles doesn't work with Apache Common Logging > -------------------------------------------------------- > > Key: WFCORE-254 > URL: https://issues.jboss.org/browse/WFCORE-254 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Anders Welen > Assignee: James Perkins > Priority: Minor > Attachments: 87905.tar > > > The logging for one logging-profile ends up in another logging-profile from time to time. It's not sporadic as all logging will end up in the wrong place when things go wrong. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 17:36:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 14 Nov 2014 17:36:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-254) logging-profiles doesn't work with Apache Common Logging In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-254: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1164063 > logging-profiles doesn't work with Apache Common Logging > -------------------------------------------------------- > > Key: WFCORE-254 > URL: https://issues.jboss.org/browse/WFCORE-254 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Anders Welen > Assignee: James Perkins > Priority: Minor > Attachments: 87905.tar > > > The logging for one logging-profile ends up in another logging-profile from time to time. It's not sporadic as all logging will end up in the wrong place when things go wrong. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 17:59:30 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 14 Nov 2014 17:59:30 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3707) ":read-log-file" op throws OutOfMemoryError for big values of parameter "lines" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFLY-3707. ------------------------------- Resolution: Out of Date Closing as the operations have changed. It's possible to still see this if a large number of lines are requested, but at the point it would make sense to use the new stream option. > ":read-log-file" op throws OutOfMemoryError for big values of parameter "lines" > ------------------------------------------------------------------------------- > > Key: WFLY-3707 > URL: https://issues.jboss.org/browse/WFLY-3707 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: Harald Pehl > Assignee: James Perkins > > When passing big values for parameter "line" of the ":read-log-file" operation the servers throws an OutOfMemoryError. > Maybe the parameter should be limited to a reasonable max-value. > If #lines(log-file) < parameter(lines) no OOME should happen at all. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 18:01:29 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 14 Nov 2014 18:01:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-255) Boot time only system properties should not modify the runtime only the model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins moved WFLY-3545 to WFCORE-255: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-255 (was: WFLY-3545) Component/s: Domain Management (was: Domain Management) Fix Version/s: (was: 9.0.0.Beta1) (was: 8.2.0.CR1) > Boot time only system properties should not modify the runtime only the model > ----------------------------------------------------------------------------- > > Key: WFCORE-255 > URL: https://issues.jboss.org/browse/WFCORE-255 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: James Perkins > > The three properties {{jboss.server.base.dir}}, {{jboss.server.config.dir}} and {{jboss.server.log.dir}} are allowed to be overridden for servers. They cannot be set as a system-property resource, but can be overridden via {{JAVA_OPTS}} or the command line. For a domain server these values need to be allowed to be set as a {{boot-time=true}} system property. > The {{add}}, {{write-attribute}} and {{remove}} operations should not modify the runtime, but should modify the model. It's debatable whether the server should be put in a {{restart-required}} state. Currently similar resources do _not_ set the server state to {{restart-required}}. For now we should stick with the same state. > {code} > [domain at localhost:9999 /] /host=master/system-property=jboss.server.log.dir:add(boot-time=true,value="/var/log") > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.", > "rolled-back" => true, > "server-groups" => {"main-server-group" => {"host" => {"master" => { > "server-one" => {"response" => { > "outcome" => "failed", > "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line", > > "rolled-back" => true > }}, > "server-two" => {"response" => { > "outcome" => "failed", > "failure-description" => "JBAS015845: System property jboss.server.log.dir cannot be set via the xml configuration file or from a management client; it's value must be known at initial process start so it can only set from the commmand line", > "rolled-back" => true > }} > }}}} > } > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 19:01:29 2014 From: issues at jboss.org (deepak vohra (JIRA)) Date: Fri, 14 Nov 2014 19:01:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4087) Java EE 7 project labeled as Java EE 6 In-Reply-To: References: Message-ID: deepak vohra created WFLY-4087: ---------------------------------- Summary: Java EE 7 project labeled as Java EE 6 Key: WFLY-4087 URL: https://issues.jboss.org/browse/WFLY-4087 Project: WildFly Issue Type: Feature Request Reporter: deepak vohra Assignee: Jason Greene -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 14 19:03:29 2014 From: issues at jboss.org (deepak vohra (JIRA)) Date: Fri, 14 Nov 2014 19:03:29 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4087) Java EE 7 project labeled as Java EE 6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020299#comment-13020299 ] deepak vohra commented on WFLY-4087: ------------------------------------ Create a Java EE Web project in Eclipse Luna with JBoss Tools 4.2.0. The Java EE Web Project wizard indicates that the Maven project is Java EE 6, but actually a Java EE 7 Maven project is created. > Java EE 7 project labeled as Java EE 6 > -------------------------------------- > > Key: WFLY-4087 > URL: https://issues.jboss.org/browse/WFLY-4087 > Project: WildFly > Issue Type: Feature Request > Reporter: deepak vohra > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 15 12:59:39 2014 From: issues at jboss.org (Alarik Myrin (JIRA)) Date: Sat, 15 Nov 2014 12:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4088) NPE when changing scheduled service In-Reply-To: References: Message-ID: Alarik Myrin created WFLY-4088: ---------------------------------- Summary: NPE when changing scheduled service Key: WFLY-4088 URL: https://issues.jboss.org/browse/WFLY-4088 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 8.0.0.Final Reporter: Alarik Myrin Assignee: David Lloyd If I modify or remove a (persistent) scheduled service, I get the following stack trace: Caused by: java.lang.NullPointerException at org.jboss.as.ejb3.timerservice.TimerServiceImpl.doesTimeoutMethodMatch(TimerServiceImpl.java:959) at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:710) at org.jboss.as.ejb3.timerservice.TimerServiceImpl.start(TimerServiceImpl.java:202) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final] ... 3 more Another user is reporting the same thing on 8.1.0 Final, see: http://stackoverflow.com/questions/25988818/deploying-java-schedule-with-wildfly-8-1-0-final Is there any way using the CLI to delete persistent scheduled services? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 15 13:00:39 2014 From: issues at jboss.org (Alarik Myrin (JIRA)) Date: Sat, 15 Nov 2014 13:00:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4088) NPE when changing scheduled service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020312#comment-13020312 ] Alarik Myrin commented on WFLY-4088: ------------------------------------ I am able to delete the persistent scheduled service in the data/timer-service-data directory. But still, the NPE is not very elegant. > NPE when changing scheduled service > ----------------------------------- > > Key: WFLY-4088 > URL: https://issues.jboss.org/browse/WFLY-4088 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Alarik Myrin > Assignee: David Lloyd > > If I modify or remove a (persistent) scheduled service, I get the following stack trace: > Caused by: java.lang.NullPointerException > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.doesTimeoutMethodMatch(TimerServiceImpl.java:959) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:710) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.start(TimerServiceImpl.java:202) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final] > ... 3 more > Another user is reporting the same thing on 8.1.0 Final, see: > http://stackoverflow.com/questions/25988818/deploying-java-schedule-with-wildfly-8-1-0-final > Is there any way using the CLI to delete persistent scheduled services? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 16 08:39:39 2014 From: issues at jboss.org (Marc Dzaebel (JIRA)) Date: Sun, 16 Nov 2014 08:39:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Duplicate method call inside patterns In-Reply-To: References: Message-ID: Marc Dzaebel created DROOLS-651: ----------------------------------- Summary: Duplicate method call inside patterns Key: DROOLS-651 URL: https://issues.jboss.org/browse/DROOLS-651 Project: Drools Issue Type: Bug Affects Versions: 6.2.0.Beta3 Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) Reporter: Marc Dzaebel Assignee: Mark Proctor Priority: Minor Create sample Drools project, add following method to the Message class: {noformat} public List list() { System.out.println("Call!"); return Arrays.asList("one", "two"); } {noformat} sample.drl: {noformat} package com.sample import com.sample.DroolsTest.Message; import java.util.List; import java.util.ArrayList; rule "" when m : Message(L : list(), L.size>0) then System.out.println("L:"+L); end {noformat} Running the project will result in the following output: {noformat} Call! Call! L:[one, two] {noformat} So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 16 18:16:39 2014 From: issues at jboss.org (James Livingston (JIRA)) Date: Sun, 16 Nov 2014 18:16:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments In-Reply-To: References: Message-ID: James Livingston created WFLY-4089: -------------------------------------- Summary: ServletContainerInitializerDeploymentProcessor does not handle comments Key: WFLY-4089 URL: https://issues.jboss.org/browse/WFLY-4089 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 9.0.0.Alpha1 Reporter: James Livingston Assignee: Stuart Douglas ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 16 18:34:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sun, 16 Nov 2014 18:34:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4089: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1164600 > ServletContainerInitializerDeploymentProcessor does not handle comments > ----------------------------------------------------------------------- > > Key: WFLY-4089 > URL: https://issues.jboss.org/browse/WFLY-4089 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: James Livingston > Assignee: Stuart Douglas > > ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. > The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. > Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 16 18:51:39 2014 From: issues at jboss.org (James Livingston (JIRA)) Date: Sun, 16 Nov 2014 18:51:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020345#comment-13020345 ] James Livingston commented on WFLY-4089: ---------------------------------------- I was looking at the wrong branch, sorry. It does attempt to handle comments, but lines containing only comments and whitespace are not handled properly because the isEmpty() check is done prior to the comment section being removed. > ServletContainerInitializerDeploymentProcessor does not handle comments > ----------------------------------------------------------------------- > > Key: WFLY-4089 > URL: https://issues.jboss.org/browse/WFLY-4089 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: James Livingston > Assignee: Stuart Douglas > > ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. > The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. > Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 16 18:52:39 2014 From: issues at jboss.org (James Livingston (JIRA)) Date: Sun, 16 Nov 2014 18:52:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020345#comment-13020345 ] James Livingston edited comment on WFLY-4089 at 11/16/14 6:52 PM: ------------------------------------------------------------------ I was looking at the wrong branch, sorry. It does attempt to handle comments, but lines containing only comments and whitespace are not handled properly because the isEmpty() check is done prior to the comment section being removed, and it checks the index of # is >0 not >= 0 was (Author: jameslivingston): I was looking at the wrong branch, sorry. It does attempt to handle comments, but lines containing only comments and whitespace are not handled properly because the isEmpty() check is done prior to the comment section being removed. > ServletContainerInitializerDeploymentProcessor does not handle comments > ----------------------------------------------------------------------- > > Key: WFLY-4089 > URL: https://issues.jboss.org/browse/WFLY-4089 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: James Livingston > Assignee: Stuart Douglas > > ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. > The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. > Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 16 19:11:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sun, 16 Nov 2014 19:11:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-202) Deadlock when shutdown Wildfly server during CLI client connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020348#comment-13020348 ] RH Bugzilla Integration commented on WFCORE-202: ------------------------------------------------ Chao Wang changed the Status of [bug 1151960|https://bugzilla.redhat.com/show_bug.cgi?id=1151960] from NEW to POST > Deadlock when shutdown Wildfly server during CLI client connection > ------------------------------------------------------------------ > > Key: WFCORE-202 > URL: https://issues.jboss.org/browse/WFCORE-202 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha10 > Reporter: Chao Wang > Assignee: Alexey Loubyansky > > Creating upstream issue as the same deadlock can be found in WFLY. > Descirption as comment 5 in [BZ1142538|https://bugzilla.redhat.com/show_bug.cgi?id=1142538] > {noformat} > The following deadlock still exists. > Steps to Reproduce: > 1. Prepare a running EAP instance with secured management port - optionally in VM > 2. Execute export JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" > 3. In the same terminal, execute "bin/jboss-cli.sh --connect --controller=$EAP_IP --user=admin --password=password ':read-resource'" > 4. From yet another terminal, execute "jdb -attach localhost:8787" > 5. In JDB: > 5.a. Create breakpoint: "stop in org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 5.b. Resume all threads: "resume" > 5.c. [Execute five times] Wait until breakpoint is hit and execute "resume". Either set timeout or be fast so that timeout does not occur first > 6. Execute "kill -9 $EAP_PID" - optionally in VM > 7. In JDB: > 8.a. Remove breakpoint: "clear org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 8.b. Resume all threads: "resume" > 9. Now dump the stack trace of jboss-cli.sh: "kill -3 $JBOSS_CLI_PID" > Found one Java-level deadlock: > ============================= > "Remoting "cli-client" read-1": > waiting to lock monitor 0x00007ff9c829b558 (object 0x0000000783433408, a java.lang.String), > which is held by "main" > "main": > waiting to lock monitor 0x00007ff9c8333c48 (object 0x00000007851ae6e0, a java.util.ArrayDeque), > which is held by "Remoting "cli-client" read-1" > Java stack information for the threads listed above: > =================================================== > "Remoting "cli-client" read-1": > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:286) > - waiting to lock <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:269) > at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54) > at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:532) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) > at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:392) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:109) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:81) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:183) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.nio.NioHandle.run(NioHandle.java:90) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:198) > "main": > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:361) > - waiting to lock <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.connectionOpened(FutureManagementChannel.java:217) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:78) > - locked <0x0000000784978a00> (a org.jboss.as.protocol.ProtocolConnectionManager) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160) > - locked <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:123) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:98) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:980) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:841) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:817) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:250) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > 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:483) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > {noformat} > It can be easily reproduce with Eclipse as: > {noformat} > 1 start Wildfly > 2 uncomment "JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" in jboss-cli.sh and connect to server > 3 add two break points at > CLIModelControllerClient$ChannelCloseHandler [line: 285] - handleClose(Channel, IOException) > RemoteConnectionChannel [line: 360] - receiveMessage(Receiver) > 4 connect to 8787 from eclipse debug > 5 shutdown Wildfly > A deadlock between "main" and "cli-client" is in Eclipse debug stack. > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 16 20:34:39 2014 From: issues at jboss.org (Davide Sottara (JIRA)) Date: Sun, 16 Nov 2014 20:34:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Duplicate method call inside patterns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020353#comment-13020353 ] Davide Sottara commented on DROOLS-651: --------------------------------------- Drools "variables" are not variables at all, but "bindings": no value is cached internally. In your example, you see two invocations: once during the evaluation of the LHS, once when the RHS is executed. The decision is not so much based on performance, but correctness. It is good practice to ensure that methods used in constraints are idempotent (i.e. they cause no state change inside the object and always return the same value), at least during the lifecycle of a rule - from evaluation to firing, otherwise the engine needs to be notified using "modify/update". If you can't or desire not to guarantee this property, Drools won't enforce it caching the first value returned. I'm inclined to reject this ticket, at least as a bug. We may consider a feature request, but this kind of internal variables are not exactly in the spirit of declarative programming :) Open for further discussion Davide > Duplicate method call inside patterns > ------------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mark Proctor > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 02:50:39 2014 From: issues at jboss.org (Tero Leppikangas (JIRA)) Date: Mon, 17 Nov 2014 02:50:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1897) ENCRYPT might drop messages during key change In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020368#comment-13020368 ] Tero Leppikangas commented on JGRP-1897: ---------------------------------------- After some more testing we found out that the fix is not working, additional work is needed. I will return to this problem after I have sorted out more urgent issues. > ENCRYPT might drop messages during key change > --------------------------------------------- > > Key: JGRP-1897 > URL: https://issues.jboss.org/browse/JGRP-1897 > Project: JGroups > Issue Type: Bug > Reporter: Tero Leppikangas > Assignee: Bela Ban > Fix For: 3.6.1 > > > ENCRYPT might drop some (unicast) messages encrypted with unknown key if the delivery of new view is delayed. > This problem was noticed while doing some stress testing on the fix for JGRP-1893. > When view changes, coordinator multicasts the new view after which is starts using new symmetric keys. If some node receives a message sent with the new key before the new view is received, the received message will be dropped since it cannot be decrypted. > We thought of possible solutions to be. > 1. Sender specific queue holding the messages received. > 2. Starting to queue up messages until new view has been received > I have implemented the second option which is quite straightforward, but it could lead into problems when receiving message with unknown key that is not related to coming view change. > I wonder if there is another way to overcome this problem? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 03:26:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 03:26:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4079) Wildfly does not consider methods with no method-intf element when resolving transaction attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020376#comment-13020376 ] RH Bugzilla Integration commented on WFLY-4079: ----------------------------------------------- Kabir Khan changed the Status of [bug 1164060|https://bugzilla.redhat.com/show_bug.cgi?id=1164060] from NEW to MODIFIED > Wildfly does not consider methods with no method-intf element when resolving transaction attributes > --------------------------------------------------------------------------------------------------- > > Key: WFLY-4079 > URL: https://issues.jboss.org/browse/WFLY-4079 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > If there is a method without a method-intf the ejb-jar.xml it will not be considered when determining the transaction attribute. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 03:58:39 2014 From: issues at jboss.org (Wolf-Dieter Fink (JIRA)) Date: Mon, 17 Nov 2014 03:58:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4090) Ability to add an alias for ejb invocations In-Reply-To: References: Message-ID: Wolf-Dieter Fink created WFLY-4090: -------------------------------------- Summary: Ability to add an alias for ejb invocations Key: WFLY-4090 URL: https://issues.jboss.org/browse/WFLY-4090 Project: WildFly Issue Type: Feature Request Affects Versions: 8.1.0.Final Reporter: Wolf-Dieter Fink Assignee: Jason Greene By default a EJB will install standards a JNDI name like //! Additional JNDI entries, i.e. for internal use or remote naming , could be installed by @Resource annotation or jboss-ejb3.xml descriptor. But it is not possiblet to use the ejb-client approach with an "ejb:" lookup to retrieve a remote-reference to this EJB. For applicaion backward compatibility it should be possible to install aliases like ejb/MyBean myapp/mymodule/MyBean/myView with different values than the unique installed one and useable by the "ejb:" context. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 04:28:39 2014 From: issues at jboss.org (Marcin Krajewski (JIRA)) Date: Mon, 17 Nov 2014 04:28:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-149) Second level cache - load object after create in same session - incorrect date In-Reply-To: References: Message-ID: Marcin Krajewski created HIBERNATE-149: ------------------------------------------ Summary: Second level cache - load object after create in same session - incorrect date Key: HIBERNATE-149 URL: https://issues.jboss.org/browse/HIBERNATE-149 Project: Hibernate Integration Issue Type: Bug Environment: Spring 4.1.0.RC2, Hibernate 4.3.6.Final Reporter: Marcin Krajewski Assignee: Steve Ebersole 1. Configure sessionFactory in applicationContext.xml to use second level cache: {code:xml} ... true true org.hibernate.cache.ehcache.EhCacheRegionFactory {code} 2. Entities to save: cache version: {code:java} @Entity @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) @Table(name = "SLO_MKRAJEWSKI") public class CacheMkrajewski { private Long id; @Id @Column(name = "COLUMN2", nullable = false, precision = 10, scale = 0) @SequenceGenerator(name = "seq_mkrajewski", sequenceName = "seq_mkrajewski", allocationSize = 1) @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_mkrajewski") public Long getId() { return this.id; } public void setId(Long id) { this.id = id; } private Date dataOd; @Temporal(TemporalType.DATE) @Column(name = "COLUMN1") public Date getDataOd() { return this.dataOd; } public void setDataOd(Date dataOd) { this.dataOd = dataOd; } @Override public String toString() { return "CacheMkrajewski [id=" + this.id + ", dataOd=" + this.dataOd + "]"; } } {code} no cache version: {code:java} @Entity @Table(name = "SLO_MKRAJEWSKI") public class NoCacheMkrajewski { private Long id; @Id @Column(name = "COLUMN2", nullable = false, precision = 10, scale = 0) @SequenceGenerator(name = "seq_mkrajewski", sequenceName = "seq_mkrajewski", allocationSize = 1) @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_mkrajewski") public Long getId() { return this.id; } public void setId(Long id) { this.id = id; } private Date dataOd; @Temporal(TemporalType.DATE) @Column(name = "COLUMN1") public Date getDataOd() { return this.dataOd; } public void setDataOd(Date dataOd) { this.dataOd = dataOd; } @Override public String toString() { return "NoCacheMkrajewski [id=" + this.id + ", dataOd=" + this.dataOd + "]"; } } {code} you can see that difference is only in removing @Cache adnotation for no cache class definition 3. Injecting sessionFactory in DAO: {code:java} @Autowired private SessionFactory sessionFactory; private Session getSession() { return this.sessionFactory.getCurrentSession(); } {code} 4. Creating model in DAO: cache version {code:java} public void save(CacheMkrajewski model) { getSession().persist(model); } {code} or no cache version: {code:java} public void save(NoCacheMkrajewski model) { getSession().persist(model); } {code} same way 5. Loading model in DAO: cache version {code:java} public CacheMkrajewski loadCache(Long id) { return (CacheMkrajewski) getSession().get(CacheMkrajewski.class, id); } {code} no cache version {code:java} public NoCacheMkrajewski loadNoCache(Long id) { return (NoCacheMkrajewski) getSession().get(NoCacheMkrajewski.class, id); } {code} 6. Injection DAO in business layer: business interface {code:java} public interface ITestBusiness { CacheMkrajewski loadCache(Long id); void save(CacheMkrajewski model); NoCacheMkrajewski loadNoCache(Long id); void save(NoCacheMkrajewski model); } {code} Business impl {code:java} @Component @Transactional public class TestBusiness implements ITestBusiness { @Autowired private TestDao dao; @Override public CacheMkrajewski loadCache(Long id) { return this.dao.loadCache(id); } @Override public void save(CacheMkrajewski model) { this.dao.save(model); } @Override public NoCacheMkrajewski loadNoCache(Long id) { return this.dao.loadNoCache(id); } @Override public void save(NoCacheMkrajewski model) { this.dao.save(model); } } {code} 7. invoke JUnit {code:java} @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = {"classpath:/mkrajewski/applicationContext-cache.xml" }) public class DateCacheTest { @Autowired private ITestBusiness testBusiness; @Before public void before() { } @Test public void cacheTest() { CacheMkrajewski cached = cacheEntity(); this.testBusiness.save(cached); cached = this.testBusiness.loadCache(cached.getId()); CacheMkrajewski loaded = this.testBusiness.loadCache(61L); System.out.println(); System.out.println("Cache " + cached); System.out.println("Loaded " + loaded); System.out.println(); } @Test public void noCacheTest() { NoCacheMkrajewski noCached = noCacheEntity(); this.testBusiness.save(noCached); noCached = this.testBusiness.loadNoCache(noCached.getId()); NoCacheMkrajewski loaded = this.testBusiness.loadNoCache(61L); System.out.println(); System.out.println("No cache " + noCached); System.out.println("Loaded " + loaded); System.out.println(); } private CacheMkrajewski cacheEntity() { CacheMkrajewski cache = new CacheMkrajewski(); cache.setDataOd(dateWithNoTime()); return cache; } private NoCacheMkrajewski noCacheEntity() { NoCacheMkrajewski noCache = new NoCacheMkrajewski(); noCache.setDataOd(dateWithNoTime()); return noCache; } private Date dateWithNoTime() { Calendar calendar = Calendar.getInstance(); calendar.clear(); calendar.set(Calendar.YEAR, 2014); calendar.set(Calendar.MONTH, 10); calendar.set(Calendar.DAY_OF_MONTH, 20); return calendar.getTime(); } } {code} we can assume that in database exists object with ID 61 8. Differences in System.outs - toString() difference: cache version {code} Cache CacheMkrajewski [id=130, dataOd=Thu Nov 20 00:00:00 CET 2014] Loaded CacheMkrajewski [id=61, dataOd=2014-11-20] {code} no cache version {code} No cache NoCacheMkrajewski [id=131, dataOd=2014-11-20] Loaded NoCacheMkrajewski [id=61, dataOd=2014-11-20] {code} When we read object created in the same session using second level cache - there is problem with date object. In new object minutes, seconds and CEST is added. When read object created in previous session (id 61) problem disappear. Problem does not exists if we use entity with disabled @Cache Full date objects from eclipse DEBUGGER: {code} CACHE OBJECT "dataOd Date (id=72) " Thu Nov 20 00:00:00 CET 2014 " cdate Gregorian$Date (id=82) " 2014-11-20T00:00:00.000+0100 " cachedFixedDateJan1 735234 " 735234 " cachedFixedDateNextJan1 735599 " 735599 " cachedYear 2014 " 2014 " daylightSaving 0 " 0 " dayOfMonth 20 " 20 " dayOfWeek 5 " 5 " era null " null " forceStandardTime false " FALSE " fraction 0 " 0 " hours 0 " 0 " leapYear false " FALSE " locale null " null " millis 0 " 0 " minutes 0 " 0 " month 11 " 11 " normalized true " TRUE " seconds 0 " 0 " year 2014 " 2014 " zoneinfo ZoneInfo (id=86) " sun.util.calendar.ZoneInfo[id="Europe/Warsaw",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=165,lastRule=java.util.SimpleTimeZone[id=Europe/Warsaw,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]] " checksum -1578751392 " -1578751392 " dirty false " FALSE " dstSavings 3600000 " 3600000 " ID ""Europe/Warsaw"" (id=92) " Europe/Warsaw " count 13 " 13 " hash 826225934 " 826225934 " offset 0 " 0 " value (id=100) " [E, u, r, o, p, e, /, W, a, r, s, a, w] " [0] E " E " [1] u " u " [2] r " r " [3] o " o " [4] p " p " [5] e " e " [6] / " / " [7] W " W " [8] a " a " [9] r " r " [10] s " s " [11] a " a " [12] w " w " lastRule null " null " offsets (id=95) " [3600000, 5040000, 7200000, 3600000, 10800000] " [0] 3600000 " 3600000 " [1] 5040000 " 5040000 " [2] 7200000 " 7200000 " [3] 3600000 " 3600000 " [4] 10800000 " 10800000 " rawOffset 3600000 " 3600000 " rawOffsetDiff 0 " 0 " simpleTimeZoneParams (id=97) " [2, -1, 1, 3600000, 2, 9, -1, 1, 3600000, 2] " [0] 2 " 2 " [1] -1 " -1 " [2] 1 " 1 " [3] 3600000 " 3600000 " [4] 2 " 2 " [5] 9 " 9 " [6] -1 " -1 " [7] 1 " 1 " [8] 3600000 " 3600000 " [9] 2 " 2 " transitions (id=98) " [-9048018124799999, -7032964055040000, -6937421414399950, -6883260825600000, -6813514137599950, -6759014400000000, -6684696575999950, -6630196838399998, -6555539865599948, -6501040127999998, -6151068057600000, -3816382463999950, -3511325491200000, -3459303014399950, -3392416972800000, -3328008191999950, -3262906368000000, -3189664972799950, -3123855360000000, -3065801932799950, -3003487027200000, -2929523097599950, -2875023360000000, -2805660057599950, -2746205798400000, -2679319756799950, -2617388236800000, -1626498662399950, -1584385228800000, -1519976447999950, -1455567667200000, -1368863539199950, -1324272844800000, -1259864063999950, -1195455283200000, -1111228415999950, -1066637721600000, -982410854399950, -937820160000000, -853593292799950, -809002598400000, -722298470399950, -680185036800000, 937466265600050, 999397785600000, 1066283827200050, 1130692608000000, 1195101388800050, 1259510169600000, 1326396211200050, 1388327731200000, 1452736512000050, 1517145292800000, 1581554073600050, 1645962854400000, 1710371635200050, 1774780416000000, 1839189196800050, 1906075238400000, 1970484019200050, 2034892800000000, 2099301580800050, 2163710361600000, 2228119142400050, 2292527923200000, 2356951449600050, 2421360230400000, 2485769011200050, 2550177792000000, 2614586572800050, 2681472614400000, 2745881395200050, 2810290176000000, 2874698956800050, 2939107737600000, 3003516518400050, 3067925299200000, 3132334080000050, 3196742860800000, 3261151641600050, 3325560422400000, 3392446464000050, 3466764288000000, 3521264025600050, 3595581849600000, 3650081587200050, 3724399411200000, 3778899148800050, 3855694233600000, 3907716710400050, 3984511795200000, 4036534272000050, 4113329356800000, 4167829094400050, 4242146918400000, 4296646656000050, 4370964480000000, 4425464217600050, 4502259302400000, 4554281779200050, 4631076864000000, 4683099340800050, 4759894425600000, 4811916902400050, 4888711987200000, 4943211724800050, 5017529548800000, 5072029286400050, 5146347110400000, 5200846848000050, 5277641932800000, 5329664409600050, 5406459494400000, 5458481971200050, 5535277056000000, 5589776793600050, 5664094617600000, 5718594355200050, 5792912179200000, 5847411916800050, 5921729740800000, 5976229478400050, 6053024563200000, 6105047040000050, 6181842124800000, 6233864601600050, 6310659686400000, 6365159424000050, 6439477248000000, 6493976985600050, 6568294809600000, 6622794547200050, 6699589632000000, 6751612108800050, 6828407193600000, 6880429670400050, 6957224755200000, 7011724492800050, 7086042316800000, 7140542054400050, 7214859878400000, 7269359616000050, 7343677440000000, 7398177177600050, 7474972262400000, 7526994739200050, 7603789824000000, 7655812300800050, 7732607385600000, 7787107123200050, 7861424947200000, 7915924684800050, 7990242508800000, 8044742246400050, 8121537331200000, 8173559808000050, 8250354892800000, 8302377369600050, 8379172454400000, 8431194931200050, 8507990016000000, 8562489753600050, 8636807577600000, 8691307315200050, 8765625139200000] " [0...99] " " [0] -9048018124799999 " -9048018124800000 " [1] -7032964055040000 " -7032964055040000 " [2] -6937421414399950 " -6937421414399950 " [3] -6883260825600000 " -6883260825600000 " [4] -6813514137599950 " -6813514137599950 " [5] -6759014400000000 " -6759014400000000 " [6] -6684696575999950 " -6684696575999950 " [7] -6630196838399998 " -6630196838400000 " [8] -6555539865599948 " -6555539865599950 " [9] -6501040127999998 " -6501040128000000 " [10] -6151068057600000 " -6151068057600000 " [11] -3816382463999950 " -3816382463999950 " [12] -3511325491200000 " -3511325491200000 " [13] -3459303014399950 " -3459303014399950 " [14] -3392416972800000 " -3392416972800000 " [15] -3328008191999950 " -3328008191999950 " [16] -3262906368000000 " -3262906368000000 " [17] -3189664972799950 " -3189664972799950 " [18] -3123855360000000 " -3123855360000000 " [19] -3065801932799950 " -3065801932799950 " [20] -3003487027200000 " -3003487027200000 " [21] -2929523097599950 " -2929523097599950 " [22] -2875023360000000 " -2875023360000000 " [23] -2805660057599950 " -2805660057599950 " [24] -2746205798400000 " -2746205798400000 " [25] -2679319756799950 " -2679319756799950 " [26] -2617388236800000 " -2617388236800000 " [27] -1626498662399950 " -1626498662399950 " [28] -1584385228800000 " -1584385228800000 " [29] -1519976447999950 " -1519976447999950 " [30] -1455567667200000 " -1455567667200000 " [31] -1368863539199950 " -1368863539199950 " [32] -1324272844800000 " -1324272844800000 " [33] -1259864063999950 " -1259864063999950 " [34] -1195455283200000 " -1195455283200000 " [35] -1111228415999950 " -1111228415999950 " [36] -1066637721600000 " -1066637721600000 " [37] -982410854399950 " -982410854399950 " [38] -937820160000000 " -937820160000000 " [39] -853593292799950 " -853593292799950 " [40] -809002598400000 " -809002598400000 " [41] -722298470399950 " -722298470399950 " [42] -680185036800000 " -680185036800000 " [43] 937466265600050 " 937466265600050 " [44] 999397785600000 " 999397785600000 " [45] 1066283827200050 " 1066283827200050 " [46] 1130692608000000 " 1130692608000000 " [47] 1195101388800050 " 1195101388800050 " [48] 1259510169600000 " 1259510169600000 " [49] 1326396211200050 " 1326396211200050 " [50] 1388327731200000 " 1388327731200000 " [51] 1452736512000050 " 1452736512000050 " [52] 1517145292800000 " 1517145292800000 " [53] 1581554073600050 " 1581554073600050 " [54] 1645962854400000 " 1645962854400000 " [55] 1710371635200050 " 1710371635200050 " [56] 1774780416000000 " 1774780416000000 " [57] 1839189196800050 " 1839189196800050 " [58] 1906075238400000 " 1906075238400000 " [59] 1970484019200050 " 1970484019200050 " [60] 2034892800000000 " 2034892800000000 " [61] 2099301580800050 " 2099301580800050 " [62] 2163710361600000 " 2163710361600000 " [63] 2228119142400050 " 2228119142400050 " [64] 2292527923200000 " 2292527923200000 " [65] 2356951449600050 " 2356951449600050 " [66] 2421360230400000 " 2421360230400000 " [67] 2485769011200050 " 2485769011200050 " [68] 2550177792000000 " 2550177792000000 " [69] 2614586572800050 " 2614586572800050 " [70] 2681472614400000 " 2681472614400000 " [71] 2745881395200050 " 2745881395200050 " [72] 2810290176000000 " 2810290176000000 " [73] 2874698956800050 " 2874698956800050 " [74] 2939107737600000 " 2939107737600000 " [75] 3003516518400050 " 3003516518400050 " [76] 3067925299200000 " 3067925299200000 " [77] 3132334080000050 " 3132334080000050 " [78] 3196742860800000 " 3196742860800000 " [79] 3261151641600050 " 3261151641600050 " [80] 3325560422400000 " 3325560422400000 " [81] 3392446464000050 " 3392446464000050 " [82] 3466764288000000 " 3466764288000000 " [83] 3521264025600050 " 3521264025600050 " [84] 3595581849600000 " 3595581849600000 " [85] 3650081587200050 " 3650081587200050 " [86] 3724399411200000 " 3724399411200000 " [87] 3778899148800050 " 3778899148800050 " [88] 3855694233600000 " 3855694233600000 " [89] 3907716710400050 " 3907716710400050 " [90] 3984511795200000 " 3984511795200000 " [91] 4036534272000050 " 4036534272000050 " [92] 4113329356800000 " 4113329356800000 " [93] 4167829094400050 " 4167829094400050 " [94] 4242146918400000 " 4242146918400000 " [95] 4296646656000050 " 4296646656000050 " [96] 4370964480000000 " 4370964480000000 " [97] 4425464217600050 " 4425464217600050 " [98] 4502259302400000 " 4502259302400000 " [99] 4554281779200050 " 4554281779200050 " [100...164] " " [100] 4631076864000000 " 4631076864000000 " [101] 4683099340800050 " 4683099340800050 " [102] 4759894425600000 " 4759894425600000 " [103] 4811916902400050 " 4811916902400050 " [104] 4888711987200000 " 4888711987200000 " [105] 4943211724800050 " 4943211724800050 " [106] 5017529548800000 " 5017529548800000 " [107] 5072029286400050 " 5072029286400050 " [108] 5146347110400000 " 5146347110400000 " [109] 5200846848000050 " 5200846848000050 " [110] 5277641932800000 " 5277641932800000 " [111] 5329664409600050 " 5329664409600050 " [112] 5406459494400000 " 5406459494400000 " [113] 5458481971200050 " 5458481971200050 " [114] 5535277056000000 " 5535277056000000 " [115] 5589776793600050 " 5589776793600050 " [116] 5664094617600000 " 5664094617600000 " [117] 5718594355200050 " 5718594355200050 " [118] 5792912179200000 " 5792912179200000 " [119] 5847411916800050 " 5847411916800050 " [120] 5921729740800000 " 5921729740800000 " [121] 5976229478400050 " 5976229478400050 " [122] 6053024563200000 " 6053024563200000 " [123] 6105047040000050 " 6105047040000050 " [124] 6181842124800000 " 6181842124800000 " [125] 6233864601600050 " 6233864601600050 " [126] 6310659686400000 " 6310659686400000 " [127] 6365159424000050 " 6365159424000050 " [128] 6439477248000000 " 6439477248000000 " [129] 6493976985600050 " 6493976985600050 " [130] 6568294809600000 " 6568294809600000 " [131] 6622794547200050 " 6622794547200050 " [132] 6699589632000000 " 6699589632000000 " [133] 6751612108800050 " 6751612108800050 " [134] 6828407193600000 " 6828407193600000 " [135] 6880429670400050 " 6880429670400050 " [136] 6957224755200000 " 6957224755200000 " [137] 7011724492800050 " 7011724492800050 " [138] 7086042316800000 " 7086042316800000 " [139] 7140542054400050 " 7140542054400050 " [140] 7214859878400000 " 7214859878400000 " [141] 7269359616000050 " 7269359616000050 " [142] 7343677440000000 " 7343677440000000 " [143] 7398177177600050 " 7398177177600050 " [144] 7474972262400000 " 7474972262400000 " [145] 7526994739200050 " 7526994739200050 " [146] 7603789824000000 " 7603789824000000 " [147] 7655812300800050 " 7655812300800050 " [148] 7732607385600000 " 7732607385600000 " [149] 7787107123200050 " 7787107123200050 " [150] 7861424947200000 " 7861424947200000 " [151] 7915924684800050 " 7915924684800050 " [152] 7990242508800000 " 7990242508800000 " [153] 8044742246400050 " 8044742246400050 " [154] 8121537331200000 " 8121537331200000 " [155] 8173559808000050 " 8173559808000050 " [156] 8250354892800000 " 8250354892800000 " [157] 8302377369600050 " 8302377369600050 " [158] 8379172454400000 " 8379172454400000 " [159] 8431194931200050 " 8431194931200050 " [160] 8507990016000000 " 8507990016000000 " [161] 8562489753600050 " 8562489753600050 " [162] 8636807577600000 " 8636807577600000 " [163] 8691307315200050 " 8691307315200050 " [164] 8765625139200000 " 8765625139200000 " willGMTOffsetChange false " FALSE " zoneOffset 3600000 " 3600000 " fastTime 1416438000000 " 1416438000000 {code} {code} NO CACHE OBJECT "dataOd Date (id=123) " 2014-11-20 " cdate Gregorian$Date (id=129) " 2014-11-20T00:00:00.000+0100 " cachedFixedDateJan1 735234 " 735234 " cachedFixedDateNextJan1 735599 " 735599 " cachedYear 2014 " 2014 " daylightSaving 0 " 0 " dayOfMonth 20 " 20 " dayOfWeek 5 " 5 " era null " null " forceStandardTime false " FALSE " fraction 0 " 0 " hours 0 " 0 " leapYear false " FALSE " locale null " null " millis 0 " 0 " minutes 0 " 0 " month 11 " 11 " normalized true " TRUE " seconds 0 " 0 " year 2014 " 2014 " zoneinfo ZoneInfo (id=86) " sun.util.calendar.ZoneInfo[id="Europe/Warsaw",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=165,lastRule=java.util.SimpleTimeZone[id=Europe/Warsaw,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]] " checksum -1578751392 " -1578751392 " dirty false " FALSE " dstSavings 3600000 " 3600000 " ID ""Europe/Warsaw"" (id=92) " Europe/Warsaw " count 13 " 13 " hash 826225934 " 826225934 " offset 0 " 0 " value (id=100) " [E, u, r, o, p, e, /, W, a, r, s, a, w] " [0] E " E " [1] u " u " [2] r " r " [3] o " o " [4] p " p " [5] e " e " [6] / " / " [7] W " W " [8] a " a " [9] r " r " [10] s " s " [11] a " a " [12] w " w " lastRule null " null " offsets (id=95) " [3600000, 5040000, 7200000, 3600000, 10800000] " [0] 3600000 " 3600000 " [1] 5040000 " 5040000 " [2] 7200000 " 7200000 " [3] 3600000 " 3600000 " [4] 10800000 " 10800000 " rawOffset 3600000 " 3600000 " rawOffsetDiff 0 " 0 " simpleTimeZoneParams (id=97) " [2, -1, 1, 3600000, 2, 9, -1, 1, 3600000, 2] " [0] 2 " 2 " [1] -1 " -1 " [2] 1 " 1 " [3] 3600000 " 3600000 " [4] 2 " 2 " [5] 9 " 9 " [6] -1 " -1 " [7] 1 " 1 " [8] 3600000 " 3600000 " [9] 2 " 2 " transitions (id=98) " [-9048018124799999, -7032964055040000, -6937421414399950, -6883260825600000, -6813514137599950, -6759014400000000, -6684696575999950, -6630196838399998, -6555539865599948, -6501040127999998, -6151068057600000, -3816382463999950, -3511325491200000, -3459303014399950, -3392416972800000, -3328008191999950, -3262906368000000, -3189664972799950, -3123855360000000, -3065801932799950, -3003487027200000, -2929523097599950, -2875023360000000, -2805660057599950, -2746205798400000, -2679319756799950, -2617388236800000, -1626498662399950, -1584385228800000, -1519976447999950, -1455567667200000, -1368863539199950, -1324272844800000, -1259864063999950, -1195455283200000, -1111228415999950, -1066637721600000, -982410854399950, -937820160000000, -853593292799950, -809002598400000, -722298470399950, -680185036800000, 937466265600050, 999397785600000, 1066283827200050, 1130692608000000, 1195101388800050, 1259510169600000, 1326396211200050, 1388327731200000, 1452736512000050, 1517145292800000, 1581554073600050, 1645962854400000, 1710371635200050, 1774780416000000, 1839189196800050, 1906075238400000, 1970484019200050, 2034892800000000, 2099301580800050, 2163710361600000, 2228119142400050, 2292527923200000, 2356951449600050, 2421360230400000, 2485769011200050, 2550177792000000, 2614586572800050, 2681472614400000, 2745881395200050, 2810290176000000, 2874698956800050, 2939107737600000, 3003516518400050, 3067925299200000, 3132334080000050, 3196742860800000, 3261151641600050, 3325560422400000, 3392446464000050, 3466764288000000, 3521264025600050, 3595581849600000, 3650081587200050, 3724399411200000, 3778899148800050, 3855694233600000, 3907716710400050, 3984511795200000, 4036534272000050, 4113329356800000, 4167829094400050, 4242146918400000, 4296646656000050, 4370964480000000, 4425464217600050, 4502259302400000, 4554281779200050, 4631076864000000, 4683099340800050, 4759894425600000, 4811916902400050, 4888711987200000, 4943211724800050, 5017529548800000, 5072029286400050, 5146347110400000, 5200846848000050, 5277641932800000, 5329664409600050, 5406459494400000, 5458481971200050, 5535277056000000, 5589776793600050, 5664094617600000, 5718594355200050, 5792912179200000, 5847411916800050, 5921729740800000, 5976229478400050, 6053024563200000, 6105047040000050, 6181842124800000, 6233864601600050, 6310659686400000, 6365159424000050, 6439477248000000, 6493976985600050, 6568294809600000, 6622794547200050, 6699589632000000, 6751612108800050, 6828407193600000, 6880429670400050, 6957224755200000, 7011724492800050, 7086042316800000, 7140542054400050, 7214859878400000, 7269359616000050, 7343677440000000, 7398177177600050, 7474972262400000, 7526994739200050, 7603789824000000, 7655812300800050, 7732607385600000, 7787107123200050, 7861424947200000, 7915924684800050, 7990242508800000, 8044742246400050, 8121537331200000, 8173559808000050, 8250354892800000, 8302377369600050, 8379172454400000, 8431194931200050, 8507990016000000, 8562489753600050, 8636807577600000, 8691307315200050, 8765625139200000] " [0...99] " " [0] -9048018124799999 " -9048018124800000 " [1] -7032964055040000 " -7032964055040000 " [2] -6937421414399950 " -6937421414399950 " [3] -6883260825600000 " -6883260825600000 " [4] -6813514137599950 " -6813514137599950 " [5] -6759014400000000 " -6759014400000000 " [6] -6684696575999950 " -6684696575999950 " [7] -6630196838399998 " -6630196838400000 " [8] -6555539865599948 " -6555539865599950 " [9] -6501040127999998 " -6501040128000000 " [10] -6151068057600000 " -6151068057600000 " [11] -3816382463999950 " -3816382463999950 " [12] -3511325491200000 " -3511325491200000 " [13] -3459303014399950 " -3459303014399950 " [14] -3392416972800000 " -3392416972800000 " [15] -3328008191999950 " -3328008191999950 " [16] -3262906368000000 " -3262906368000000 " [17] -3189664972799950 " -3189664972799950 " [18] -3123855360000000 " -3123855360000000 " [19] -3065801932799950 " -3065801932799950 " [20] -3003487027200000 " -3003487027200000 " [21] -2929523097599950 " -2929523097599950 " [22] -2875023360000000 " -2875023360000000 " [23] -2805660057599950 " -2805660057599950 " [24] -2746205798400000 " -2746205798400000 " [25] -2679319756799950 " -2679319756799950 " [26] -2617388236800000 " -2617388236800000 " [27] -1626498662399950 " -1626498662399950 " [28] -1584385228800000 " -1584385228800000 " [29] -1519976447999950 " -1519976447999950 " [30] -1455567667200000 " -1455567667200000 " [31] -1368863539199950 " -1368863539199950 " [32] -1324272844800000 " -1324272844800000 " [33] -1259864063999950 " -1259864063999950 " [34] -1195455283200000 " -1195455283200000 " [35] -1111228415999950 " -1111228415999950 " [36] -1066637721600000 " -1066637721600000 " [37] -982410854399950 " -982410854399950 " [38] -937820160000000 " -937820160000000 " [39] -853593292799950 " -853593292799950 " [40] -809002598400000 " -809002598400000 " [41] -722298470399950 " -722298470399950 " [42] -680185036800000 " -680185036800000 " [43] 937466265600050 " 937466265600050 " [44] 999397785600000 " 999397785600000 " [45] 1066283827200050 " 1066283827200050 " [46] 1130692608000000 " 1130692608000000 " [47] 1195101388800050 " 1195101388800050 " [48] 1259510169600000 " 1259510169600000 " [49] 1326396211200050 " 1326396211200050 " [50] 1388327731200000 " 1388327731200000 " [51] 1452736512000050 " 1452736512000050 " [52] 1517145292800000 " 1517145292800000 " [53] 1581554073600050 " 1581554073600050 " [54] 1645962854400000 " 1645962854400000 " [55] 1710371635200050 " 1710371635200050 " [56] 1774780416000000 " 1774780416000000 " [57] 1839189196800050 " 1839189196800050 " [58] 1906075238400000 " 1906075238400000 " [59] 1970484019200050 " 1970484019200050 " [60] 2034892800000000 " 2034892800000000 " [61] 2099301580800050 " 2099301580800050 " [62] 2163710361600000 " 2163710361600000 " [63] 2228119142400050 " 2228119142400050 " [64] 2292527923200000 " 2292527923200000 " [65] 2356951449600050 " 2356951449600050 " [66] 2421360230400000 " 2421360230400000 " [67] 2485769011200050 " 2485769011200050 " [68] 2550177792000000 " 2550177792000000 " [69] 2614586572800050 " 2614586572800050 " [70] 2681472614400000 " 2681472614400000 " [71] 2745881395200050 " 2745881395200050 " [72] 2810290176000000 " 2810290176000000 " [73] 2874698956800050 " 2874698956800050 " [74] 2939107737600000 " 2939107737600000 " [75] 3003516518400050 " 3003516518400050 " [76] 3067925299200000 " 3067925299200000 " [77] 3132334080000050 " 3132334080000050 " [78] 3196742860800000 " 3196742860800000 " [79] 3261151641600050 " 3261151641600050 " [80] 3325560422400000 " 3325560422400000 " [81] 3392446464000050 " 3392446464000050 " [82] 3466764288000000 " 3466764288000000 " [83] 3521264025600050 " 3521264025600050 " [84] 3595581849600000 " 3595581849600000 " [85] 3650081587200050 " 3650081587200050 " [86] 3724399411200000 " 3724399411200000 " [87] 3778899148800050 " 3778899148800050 " [88] 3855694233600000 " 3855694233600000 " [89] 3907716710400050 " 3907716710400050 " [90] 3984511795200000 " 3984511795200000 " [91] 4036534272000050 " 4036534272000050 " [92] 4113329356800000 " 4113329356800000 " [93] 4167829094400050 " 4167829094400050 " [94] 4242146918400000 " 4242146918400000 " [95] 4296646656000050 " 4296646656000050 " [96] 4370964480000000 " 4370964480000000 " [97] 4425464217600050 " 4425464217600050 " [98] 4502259302400000 " 4502259302400000 " [99] 4554281779200050 " 4554281779200050 " [100...164] " " [100] 4631076864000000 " 4631076864000000 " [101] 4683099340800050 " 4683099340800050 " [102] 4759894425600000 " 4759894425600000 " [103] 4811916902400050 " 4811916902400050 " [104] 4888711987200000 " 4888711987200000 " [105] 4943211724800050 " 4943211724800050 " [106] 5017529548800000 " 5017529548800000 " [107] 5072029286400050 " 5072029286400050 " [108] 5146347110400000 " 5146347110400000 " [109] 5200846848000050 " 5200846848000050 " [110] 5277641932800000 " 5277641932800000 " [111] 5329664409600050 " 5329664409600050 " [112] 5406459494400000 " 5406459494400000 " [113] 5458481971200050 " 5458481971200050 " [114] 5535277056000000 " 5535277056000000 " [115] 5589776793600050 " 5589776793600050 " [116] 5664094617600000 " 5664094617600000 " [117] 5718594355200050 " 5718594355200050 " [118] 5792912179200000 " 5792912179200000 " [119] 5847411916800050 " 5847411916800050 " [120] 5921729740800000 " 5921729740800000 " [121] 5976229478400050 " 5976229478400050 " [122] 6053024563200000 " 6053024563200000 " [123] 6105047040000050 " 6105047040000050 " [124] 6181842124800000 " 6181842124800000 " [125] 6233864601600050 " 6233864601600050 " [126] 6310659686400000 " 6310659686400000 " [127] 6365159424000050 " 6365159424000050 " [128] 6439477248000000 " 6439477248000000 " [129] 6493976985600050 " 6493976985600050 " [130] 6568294809600000 " 6568294809600000 " [131] 6622794547200050 " 6622794547200050 " [132] 6699589632000000 " 6699589632000000 " [133] 6751612108800050 " 6751612108800050 " [134] 6828407193600000 " 6828407193600000 " [135] 6880429670400050 " 6880429670400050 " [136] 6957224755200000 " 6957224755200000 " [137] 7011724492800050 " 7011724492800050 " [138] 7086042316800000 " 7086042316800000 " [139] 7140542054400050 " 7140542054400050 " [140] 7214859878400000 " 7214859878400000 " [141] 7269359616000050 " 7269359616000050 " [142] 7343677440000000 " 7343677440000000 " [143] 7398177177600050 " 7398177177600050 " [144] 7474972262400000 " 7474972262400000 " [145] 7526994739200050 " 7526994739200050 " [146] 7603789824000000 " 7603789824000000 " [147] 7655812300800050 " 7655812300800050 " [148] 7732607385600000 " 7732607385600000 " [149] 7787107123200050 " 7787107123200050 " [150] 7861424947200000 " 7861424947200000 " [151] 7915924684800050 " 7915924684800050 " [152] 7990242508800000 " 7990242508800000 " [153] 8044742246400050 " 8044742246400050 " [154] 8121537331200000 " 8121537331200000 " [155] 8173559808000050 " 8173559808000050 " [156] 8250354892800000 " 8250354892800000 " [157] 8302377369600050 " 8302377369600050 " [158] 8379172454400000 " 8379172454400000 " [159] 8431194931200050 " 8431194931200050 " [160] 8507990016000000 " 8507990016000000 " [161] 8562489753600050 " 8562489753600050 " [162] 8636807577600000 " 8636807577600000 " [163] 8691307315200050 " 8691307315200050 " [164] 8765625139200000 " 8765625139200000 " willGMTOffsetChange false " FALSE " zoneOffset 3600000 " 3600000 " fastTime 1416438000000 " 1416438000000 {code} After comparing them in diff viewer - the difference is only in first two lines: |"dataOd Date (id=72) "| Thu Nov 20 00:00:00 CET 2014 |"dataOd Date (id=123) "| 2014-11-20| |" cdate Gregorian$Date (id=82) "| 2014-11-20T00:00:00.000+0100 |" cdate Gregorian$Date (id=129) "| 2014-11-20T00:00:00.000+0100| in first line - toString and id, in second line - only id Why date in object read from cache (after creating in same session) has different toString than read from no cache - objects in debugger looks same, so I really don't know what is the problem -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 04:30:39 2014 From: issues at jboss.org (Marcin Krajewski (JIRA)) Date: Mon, 17 Nov 2014 04:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (HIBERNATE-149) Second level cache - load object after create in same session - incorrect date In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/HIBERNATE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcin Krajewski updated HIBERNATE-149: --------------------------------------- Description: 1. Configure sessionFactory in applicationContext.xml to use second level cache: {code:xml} ... true true org.hibernate.cache.ehcache.EhCacheRegionFactory {code} 2. Entities to save: cache version: {code:java} @Entity @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) @Table(name = "SLO_MKRAJEWSKI") public class CacheMkrajewski { private Long id; @Id @Column(name = "COLUMN2", nullable = false, precision = 10, scale = 0) @SequenceGenerator(name = "seq_mkrajewski", sequenceName = "seq_mkrajewski", allocationSize = 1) @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_mkrajewski") public Long getId() { return this.id; } public void setId(Long id) { this.id = id; } private Date dataOd; @Temporal(TemporalType.DATE) @Column(name = "COLUMN1") public Date getDataOd() { return this.dataOd; } public void setDataOd(Date dataOd) { this.dataOd = dataOd; } @Override public String toString() { return "CacheMkrajewski [id=" + this.id + ", dataOd=" + this.dataOd + "]"; } } {code} no cache version: {code:java} @Entity @Table(name = "SLO_MKRAJEWSKI") public class NoCacheMkrajewski { private Long id; @Id @Column(name = "COLUMN2", nullable = false, precision = 10, scale = 0) @SequenceGenerator(name = "seq_mkrajewski", sequenceName = "seq_mkrajewski", allocationSize = 1) @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_mkrajewski") public Long getId() { return this.id; } public void setId(Long id) { this.id = id; } private Date dataOd; @Temporal(TemporalType.DATE) @Column(name = "COLUMN1") public Date getDataOd() { return this.dataOd; } public void setDataOd(Date dataOd) { this.dataOd = dataOd; } @Override public String toString() { return "NoCacheMkrajewski [id=" + this.id + ", dataOd=" + this.dataOd + "]"; } } {code} you can see that difference is only in removing @Cache adnotation for no cache class definition 3. Injecting sessionFactory in DAO: {code:java} @Autowired private SessionFactory sessionFactory; private Session getSession() { return this.sessionFactory.getCurrentSession(); } {code} 4. Creating model in DAO: cache version {code:java} public void save(CacheMkrajewski model) { getSession().persist(model); } {code} or no cache version: {code:java} public void save(NoCacheMkrajewski model) { getSession().persist(model); } {code} same way 5. Loading model in DAO: cache version {code:java} public CacheMkrajewski loadCache(Long id) { return (CacheMkrajewski) getSession().get(CacheMkrajewski.class, id); } {code} no cache version {code:java} public NoCacheMkrajewski loadNoCache(Long id) { return (NoCacheMkrajewski) getSession().get(NoCacheMkrajewski.class, id); } {code} 6. Injection DAO in business layer: business interface {code:java} public interface ITestBusiness { CacheMkrajewski loadCache(Long id); void save(CacheMkrajewski model); NoCacheMkrajewski loadNoCache(Long id); void save(NoCacheMkrajewski model); } {code} Business impl {code:java} @Component @Transactional public class TestBusiness implements ITestBusiness { @Autowired private TestDao dao; @Override public CacheMkrajewski loadCache(Long id) { return this.dao.loadCache(id); } @Override public void save(CacheMkrajewski model) { this.dao.save(model); } @Override public NoCacheMkrajewski loadNoCache(Long id) { return this.dao.loadNoCache(id); } @Override public void save(NoCacheMkrajewski model) { this.dao.save(model); } } {code} 7. invoke JUnit {code:java} @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = {"classpath:/mkrajewski/applicationContext-cache.xml" }) public class DateCacheTest { @Autowired private ITestBusiness testBusiness; @Before public void before() { } @Test public void cacheTest() { CacheMkrajewski cached = cacheEntity(); this.testBusiness.save(cached); cached = this.testBusiness.loadCache(cached.getId()); CacheMkrajewski loaded = this.testBusiness.loadCache(61L); System.out.println(); System.out.println("Cache " + cached); System.out.println("Loaded " + loaded); System.out.println(); } @Test public void noCacheTest() { NoCacheMkrajewski noCached = noCacheEntity(); this.testBusiness.save(noCached); noCached = this.testBusiness.loadNoCache(noCached.getId()); NoCacheMkrajewski loaded = this.testBusiness.loadNoCache(61L); System.out.println(); System.out.println("No cache " + noCached); System.out.println("Loaded " + loaded); System.out.println(); } private CacheMkrajewski cacheEntity() { CacheMkrajewski cache = new CacheMkrajewski(); cache.setDataOd(dateWithNoTime()); return cache; } private NoCacheMkrajewski noCacheEntity() { NoCacheMkrajewski noCache = new NoCacheMkrajewski(); noCache.setDataOd(dateWithNoTime()); return noCache; } private Date dateWithNoTime() { Calendar calendar = Calendar.getInstance(); calendar.clear(); calendar.set(Calendar.YEAR, 2014); calendar.set(Calendar.MONTH, 10); calendar.set(Calendar.DAY_OF_MONTH, 20); return calendar.getTime(); } } {code} we can assume that in database exists object with ID 61 8. Differences in System.outs - toString() difference: cache version {code} Cache CacheMkrajewski [id=130, dataOd=Thu Nov 20 00:00:00 CET 2014] Loaded CacheMkrajewski [id=61, dataOd=2014-11-20] {code} no cache version {code} No cache NoCacheMkrajewski [id=131, dataOd=2014-11-20] Loaded NoCacheMkrajewski [id=61, dataOd=2014-11-20] {code} When we read object created in the same session using second level cache - there is problem with date object. In new object minutes, seconds and CEST is added. When read object created in previous session (id 61) problem disappear. Problem does not exists if we use entity with disabled @Cache 9. Full date objects from eclipse DEBUGGER: {code} CACHE OBJECT "dataOd Date (id=72) " Thu Nov 20 00:00:00 CET 2014 " cdate Gregorian$Date (id=82) " 2014-11-20T00:00:00.000+0100 " cachedFixedDateJan1 735234 " 735234 " cachedFixedDateNextJan1 735599 " 735599 " cachedYear 2014 " 2014 " daylightSaving 0 " 0 " dayOfMonth 20 " 20 " dayOfWeek 5 " 5 " era null " null " forceStandardTime false " FALSE " fraction 0 " 0 " hours 0 " 0 " leapYear false " FALSE " locale null " null " millis 0 " 0 " minutes 0 " 0 " month 11 " 11 " normalized true " TRUE " seconds 0 " 0 " year 2014 " 2014 " zoneinfo ZoneInfo (id=86) " sun.util.calendar.ZoneInfo[id="Europe/Warsaw",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=165,lastRule=java.util.SimpleTimeZone[id=Europe/Warsaw,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]] " checksum -1578751392 " -1578751392 " dirty false " FALSE " dstSavings 3600000 " 3600000 " ID ""Europe/Warsaw"" (id=92) " Europe/Warsaw " count 13 " 13 " hash 826225934 " 826225934 " offset 0 " 0 " value (id=100) " [E, u, r, o, p, e, /, W, a, r, s, a, w] " [0] E " E " [1] u " u " [2] r " r " [3] o " o " [4] p " p " [5] e " e " [6] / " / " [7] W " W " [8] a " a " [9] r " r " [10] s " s " [11] a " a " [12] w " w " lastRule null " null " offsets (id=95) " [3600000, 5040000, 7200000, 3600000, 10800000] " [0] 3600000 " 3600000 " [1] 5040000 " 5040000 " [2] 7200000 " 7200000 " [3] 3600000 " 3600000 " [4] 10800000 " 10800000 " rawOffset 3600000 " 3600000 " rawOffsetDiff 0 " 0 " simpleTimeZoneParams (id=97) " [2, -1, 1, 3600000, 2, 9, -1, 1, 3600000, 2] " [0] 2 " 2 " [1] -1 " -1 " [2] 1 " 1 " [3] 3600000 " 3600000 " [4] 2 " 2 " [5] 9 " 9 " [6] -1 " -1 " [7] 1 " 1 " [8] 3600000 " 3600000 " [9] 2 " 2 " transitions (id=98) " [-9048018124799999, -7032964055040000, -6937421414399950, -6883260825600000, -6813514137599950, -6759014400000000, -6684696575999950, -6630196838399998, -6555539865599948, -6501040127999998, -6151068057600000, -3816382463999950, -3511325491200000, -3459303014399950, -3392416972800000, -3328008191999950, -3262906368000000, -3189664972799950, -3123855360000000, -3065801932799950, -3003487027200000, -2929523097599950, -2875023360000000, -2805660057599950, -2746205798400000, -2679319756799950, -2617388236800000, -1626498662399950, -1584385228800000, -1519976447999950, -1455567667200000, -1368863539199950, -1324272844800000, -1259864063999950, -1195455283200000, -1111228415999950, -1066637721600000, -982410854399950, -937820160000000, -853593292799950, -809002598400000, -722298470399950, -680185036800000, 937466265600050, 999397785600000, 1066283827200050, 1130692608000000, 1195101388800050, 1259510169600000, 1326396211200050, 1388327731200000, 1452736512000050, 1517145292800000, 1581554073600050, 1645962854400000, 1710371635200050, 1774780416000000, 1839189196800050, 1906075238400000, 1970484019200050, 2034892800000000, 2099301580800050, 2163710361600000, 2228119142400050, 2292527923200000, 2356951449600050, 2421360230400000, 2485769011200050, 2550177792000000, 2614586572800050, 2681472614400000, 2745881395200050, 2810290176000000, 2874698956800050, 2939107737600000, 3003516518400050, 3067925299200000, 3132334080000050, 3196742860800000, 3261151641600050, 3325560422400000, 3392446464000050, 3466764288000000, 3521264025600050, 3595581849600000, 3650081587200050, 3724399411200000, 3778899148800050, 3855694233600000, 3907716710400050, 3984511795200000, 4036534272000050, 4113329356800000, 4167829094400050, 4242146918400000, 4296646656000050, 4370964480000000, 4425464217600050, 4502259302400000, 4554281779200050, 4631076864000000, 4683099340800050, 4759894425600000, 4811916902400050, 4888711987200000, 4943211724800050, 5017529548800000, 5072029286400050, 5146347110400000, 5200846848000050, 5277641932800000, 5329664409600050, 5406459494400000, 5458481971200050, 5535277056000000, 5589776793600050, 5664094617600000, 5718594355200050, 5792912179200000, 5847411916800050, 5921729740800000, 5976229478400050, 6053024563200000, 6105047040000050, 6181842124800000, 6233864601600050, 6310659686400000, 6365159424000050, 6439477248000000, 6493976985600050, 6568294809600000, 6622794547200050, 6699589632000000, 6751612108800050, 6828407193600000, 6880429670400050, 6957224755200000, 7011724492800050, 7086042316800000, 7140542054400050, 7214859878400000, 7269359616000050, 7343677440000000, 7398177177600050, 7474972262400000, 7526994739200050, 7603789824000000, 7655812300800050, 7732607385600000, 7787107123200050, 7861424947200000, 7915924684800050, 7990242508800000, 8044742246400050, 8121537331200000, 8173559808000050, 8250354892800000, 8302377369600050, 8379172454400000, 8431194931200050, 8507990016000000, 8562489753600050, 8636807577600000, 8691307315200050, 8765625139200000] " [0...99] " " [0] -9048018124799999 " -9048018124800000 " [1] -7032964055040000 " -7032964055040000 " [2] -6937421414399950 " -6937421414399950 " [3] -6883260825600000 " -6883260825600000 " [4] -6813514137599950 " -6813514137599950 " [5] -6759014400000000 " -6759014400000000 " [6] -6684696575999950 " -6684696575999950 " [7] -6630196838399998 " -6630196838400000 " [8] -6555539865599948 " -6555539865599950 " [9] -6501040127999998 " -6501040128000000 " [10] -6151068057600000 " -6151068057600000 " [11] -3816382463999950 " -3816382463999950 " [12] -3511325491200000 " -3511325491200000 " [13] -3459303014399950 " -3459303014399950 " [14] -3392416972800000 " -3392416972800000 " [15] -3328008191999950 " -3328008191999950 " [16] -3262906368000000 " -3262906368000000 " [17] -3189664972799950 " -3189664972799950 " [18] -3123855360000000 " -3123855360000000 " [19] -3065801932799950 " -3065801932799950 " [20] -3003487027200000 " -3003487027200000 " [21] -2929523097599950 " -2929523097599950 " [22] -2875023360000000 " -2875023360000000 " [23] -2805660057599950 " -2805660057599950 " [24] -2746205798400000 " -2746205798400000 " [25] -2679319756799950 " -2679319756799950 " [26] -2617388236800000 " -2617388236800000 " [27] -1626498662399950 " -1626498662399950 " [28] -1584385228800000 " -1584385228800000 " [29] -1519976447999950 " -1519976447999950 " [30] -1455567667200000 " -1455567667200000 " [31] -1368863539199950 " -1368863539199950 " [32] -1324272844800000 " -1324272844800000 " [33] -1259864063999950 " -1259864063999950 " [34] -1195455283200000 " -1195455283200000 " [35] -1111228415999950 " -1111228415999950 " [36] -1066637721600000 " -1066637721600000 " [37] -982410854399950 " -982410854399950 " [38] -937820160000000 " -937820160000000 " [39] -853593292799950 " -853593292799950 " [40] -809002598400000 " -809002598400000 " [41] -722298470399950 " -722298470399950 " [42] -680185036800000 " -680185036800000 " [43] 937466265600050 " 937466265600050 " [44] 999397785600000 " 999397785600000 " [45] 1066283827200050 " 1066283827200050 " [46] 1130692608000000 " 1130692608000000 " [47] 1195101388800050 " 1195101388800050 " [48] 1259510169600000 " 1259510169600000 " [49] 1326396211200050 " 1326396211200050 " [50] 1388327731200000 " 1388327731200000 " [51] 1452736512000050 " 1452736512000050 " [52] 1517145292800000 " 1517145292800000 " [53] 1581554073600050 " 1581554073600050 " [54] 1645962854400000 " 1645962854400000 " [55] 1710371635200050 " 1710371635200050 " [56] 1774780416000000 " 1774780416000000 " [57] 1839189196800050 " 1839189196800050 " [58] 1906075238400000 " 1906075238400000 " [59] 1970484019200050 " 1970484019200050 " [60] 2034892800000000 " 2034892800000000 " [61] 2099301580800050 " 2099301580800050 " [62] 2163710361600000 " 2163710361600000 " [63] 2228119142400050 " 2228119142400050 " [64] 2292527923200000 " 2292527923200000 " [65] 2356951449600050 " 2356951449600050 " [66] 2421360230400000 " 2421360230400000 " [67] 2485769011200050 " 2485769011200050 " [68] 2550177792000000 " 2550177792000000 " [69] 2614586572800050 " 2614586572800050 " [70] 2681472614400000 " 2681472614400000 " [71] 2745881395200050 " 2745881395200050 " [72] 2810290176000000 " 2810290176000000 " [73] 2874698956800050 " 2874698956800050 " [74] 2939107737600000 " 2939107737600000 " [75] 3003516518400050 " 3003516518400050 " [76] 3067925299200000 " 3067925299200000 " [77] 3132334080000050 " 3132334080000050 " [78] 3196742860800000 " 3196742860800000 " [79] 3261151641600050 " 3261151641600050 " [80] 3325560422400000 " 3325560422400000 " [81] 3392446464000050 " 3392446464000050 " [82] 3466764288000000 " 3466764288000000 " [83] 3521264025600050 " 3521264025600050 " [84] 3595581849600000 " 3595581849600000 " [85] 3650081587200050 " 3650081587200050 " [86] 3724399411200000 " 3724399411200000 " [87] 3778899148800050 " 3778899148800050 " [88] 3855694233600000 " 3855694233600000 " [89] 3907716710400050 " 3907716710400050 " [90] 3984511795200000 " 3984511795200000 " [91] 4036534272000050 " 4036534272000050 " [92] 4113329356800000 " 4113329356800000 " [93] 4167829094400050 " 4167829094400050 " [94] 4242146918400000 " 4242146918400000 " [95] 4296646656000050 " 4296646656000050 " [96] 4370964480000000 " 4370964480000000 " [97] 4425464217600050 " 4425464217600050 " [98] 4502259302400000 " 4502259302400000 " [99] 4554281779200050 " 4554281779200050 " [100...164] " " [100] 4631076864000000 " 4631076864000000 " [101] 4683099340800050 " 4683099340800050 " [102] 4759894425600000 " 4759894425600000 " [103] 4811916902400050 " 4811916902400050 " [104] 4888711987200000 " 4888711987200000 " [105] 4943211724800050 " 4943211724800050 " [106] 5017529548800000 " 5017529548800000 " [107] 5072029286400050 " 5072029286400050 " [108] 5146347110400000 " 5146347110400000 " [109] 5200846848000050 " 5200846848000050 " [110] 5277641932800000 " 5277641932800000 " [111] 5329664409600050 " 5329664409600050 " [112] 5406459494400000 " 5406459494400000 " [113] 5458481971200050 " 5458481971200050 " [114] 5535277056000000 " 5535277056000000 " [115] 5589776793600050 " 5589776793600050 " [116] 5664094617600000 " 5664094617600000 " [117] 5718594355200050 " 5718594355200050 " [118] 5792912179200000 " 5792912179200000 " [119] 5847411916800050 " 5847411916800050 " [120] 5921729740800000 " 5921729740800000 " [121] 5976229478400050 " 5976229478400050 " [122] 6053024563200000 " 6053024563200000 " [123] 6105047040000050 " 6105047040000050 " [124] 6181842124800000 " 6181842124800000 " [125] 6233864601600050 " 6233864601600050 " [126] 6310659686400000 " 6310659686400000 " [127] 6365159424000050 " 6365159424000050 " [128] 6439477248000000 " 6439477248000000 " [129] 6493976985600050 " 6493976985600050 " [130] 6568294809600000 " 6568294809600000 " [131] 6622794547200050 " 6622794547200050 " [132] 6699589632000000 " 6699589632000000 " [133] 6751612108800050 " 6751612108800050 " [134] 6828407193600000 " 6828407193600000 " [135] 6880429670400050 " 6880429670400050 " [136] 6957224755200000 " 6957224755200000 " [137] 7011724492800050 " 7011724492800050 " [138] 7086042316800000 " 7086042316800000 " [139] 7140542054400050 " 7140542054400050 " [140] 7214859878400000 " 7214859878400000 " [141] 7269359616000050 " 7269359616000050 " [142] 7343677440000000 " 7343677440000000 " [143] 7398177177600050 " 7398177177600050 " [144] 7474972262400000 " 7474972262400000 " [145] 7526994739200050 " 7526994739200050 " [146] 7603789824000000 " 7603789824000000 " [147] 7655812300800050 " 7655812300800050 " [148] 7732607385600000 " 7732607385600000 " [149] 7787107123200050 " 7787107123200050 " [150] 7861424947200000 " 7861424947200000 " [151] 7915924684800050 " 7915924684800050 " [152] 7990242508800000 " 7990242508800000 " [153] 8044742246400050 " 8044742246400050 " [154] 8121537331200000 " 8121537331200000 " [155] 8173559808000050 " 8173559808000050 " [156] 8250354892800000 " 8250354892800000 " [157] 8302377369600050 " 8302377369600050 " [158] 8379172454400000 " 8379172454400000 " [159] 8431194931200050 " 8431194931200050 " [160] 8507990016000000 " 8507990016000000 " [161] 8562489753600050 " 8562489753600050 " [162] 8636807577600000 " 8636807577600000 " [163] 8691307315200050 " 8691307315200050 " [164] 8765625139200000 " 8765625139200000 " willGMTOffsetChange false " FALSE " zoneOffset 3600000 " 3600000 " fastTime 1416438000000 " 1416438000000 {code} {code} NO CACHE OBJECT "dataOd Date (id=123) " 2014-11-20 " cdate Gregorian$Date (id=129) " 2014-11-20T00:00:00.000+0100 " cachedFixedDateJan1 735234 " 735234 " cachedFixedDateNextJan1 735599 " 735599 " cachedYear 2014 " 2014 " daylightSaving 0 " 0 " dayOfMonth 20 " 20 " dayOfWeek 5 " 5 " era null " null " forceStandardTime false " FALSE " fraction 0 " 0 " hours 0 " 0 " leapYear false " FALSE " locale null " null " millis 0 " 0 " minutes 0 " 0 " month 11 " 11 " normalized true " TRUE " seconds 0 " 0 " year 2014 " 2014 " zoneinfo ZoneInfo (id=86) " sun.util.calendar.ZoneInfo[id="Europe/Warsaw",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=165,lastRule=java.util.SimpleTimeZone[id=Europe/Warsaw,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]] " checksum -1578751392 " -1578751392 " dirty false " FALSE " dstSavings 3600000 " 3600000 " ID ""Europe/Warsaw"" (id=92) " Europe/Warsaw " count 13 " 13 " hash 826225934 " 826225934 " offset 0 " 0 " value (id=100) " [E, u, r, o, p, e, /, W, a, r, s, a, w] " [0] E " E " [1] u " u " [2] r " r " [3] o " o " [4] p " p " [5] e " e " [6] / " / " [7] W " W " [8] a " a " [9] r " r " [10] s " s " [11] a " a " [12] w " w " lastRule null " null " offsets (id=95) " [3600000, 5040000, 7200000, 3600000, 10800000] " [0] 3600000 " 3600000 " [1] 5040000 " 5040000 " [2] 7200000 " 7200000 " [3] 3600000 " 3600000 " [4] 10800000 " 10800000 " rawOffset 3600000 " 3600000 " rawOffsetDiff 0 " 0 " simpleTimeZoneParams (id=97) " [2, -1, 1, 3600000, 2, 9, -1, 1, 3600000, 2] " [0] 2 " 2 " [1] -1 " -1 " [2] 1 " 1 " [3] 3600000 " 3600000 " [4] 2 " 2 " [5] 9 " 9 " [6] -1 " -1 " [7] 1 " 1 " [8] 3600000 " 3600000 " [9] 2 " 2 " transitions (id=98) " [-9048018124799999, -7032964055040000, -6937421414399950, -6883260825600000, -6813514137599950, -6759014400000000, -6684696575999950, -6630196838399998, -6555539865599948, -6501040127999998, -6151068057600000, -3816382463999950, -3511325491200000, -3459303014399950, -3392416972800000, -3328008191999950, -3262906368000000, -3189664972799950, -3123855360000000, -3065801932799950, -3003487027200000, -2929523097599950, -2875023360000000, -2805660057599950, -2746205798400000, -2679319756799950, -2617388236800000, -1626498662399950, -1584385228800000, -1519976447999950, -1455567667200000, -1368863539199950, -1324272844800000, -1259864063999950, -1195455283200000, -1111228415999950, -1066637721600000, -982410854399950, -937820160000000, -853593292799950, -809002598400000, -722298470399950, -680185036800000, 937466265600050, 999397785600000, 1066283827200050, 1130692608000000, 1195101388800050, 1259510169600000, 1326396211200050, 1388327731200000, 1452736512000050, 1517145292800000, 1581554073600050, 1645962854400000, 1710371635200050, 1774780416000000, 1839189196800050, 1906075238400000, 1970484019200050, 2034892800000000, 2099301580800050, 2163710361600000, 2228119142400050, 2292527923200000, 2356951449600050, 2421360230400000, 2485769011200050, 2550177792000000, 2614586572800050, 2681472614400000, 2745881395200050, 2810290176000000, 2874698956800050, 2939107737600000, 3003516518400050, 3067925299200000, 3132334080000050, 3196742860800000, 3261151641600050, 3325560422400000, 3392446464000050, 3466764288000000, 3521264025600050, 3595581849600000, 3650081587200050, 3724399411200000, 3778899148800050, 3855694233600000, 3907716710400050, 3984511795200000, 4036534272000050, 4113329356800000, 4167829094400050, 4242146918400000, 4296646656000050, 4370964480000000, 4425464217600050, 4502259302400000, 4554281779200050, 4631076864000000, 4683099340800050, 4759894425600000, 4811916902400050, 4888711987200000, 4943211724800050, 5017529548800000, 5072029286400050, 5146347110400000, 5200846848000050, 5277641932800000, 5329664409600050, 5406459494400000, 5458481971200050, 5535277056000000, 5589776793600050, 5664094617600000, 5718594355200050, 5792912179200000, 5847411916800050, 5921729740800000, 5976229478400050, 6053024563200000, 6105047040000050, 6181842124800000, 6233864601600050, 6310659686400000, 6365159424000050, 6439477248000000, 6493976985600050, 6568294809600000, 6622794547200050, 6699589632000000, 6751612108800050, 6828407193600000, 6880429670400050, 6957224755200000, 7011724492800050, 7086042316800000, 7140542054400050, 7214859878400000, 7269359616000050, 7343677440000000, 7398177177600050, 7474972262400000, 7526994739200050, 7603789824000000, 7655812300800050, 7732607385600000, 7787107123200050, 7861424947200000, 7915924684800050, 7990242508800000, 8044742246400050, 8121537331200000, 8173559808000050, 8250354892800000, 8302377369600050, 8379172454400000, 8431194931200050, 8507990016000000, 8562489753600050, 8636807577600000, 8691307315200050, 8765625139200000] " [0...99] " " [0] -9048018124799999 " -9048018124800000 " [1] -7032964055040000 " -7032964055040000 " [2] -6937421414399950 " -6937421414399950 " [3] -6883260825600000 " -6883260825600000 " [4] -6813514137599950 " -6813514137599950 " [5] -6759014400000000 " -6759014400000000 " [6] -6684696575999950 " -6684696575999950 " [7] -6630196838399998 " -6630196838400000 " [8] -6555539865599948 " -6555539865599950 " [9] -6501040127999998 " -6501040128000000 " [10] -6151068057600000 " -6151068057600000 " [11] -3816382463999950 " -3816382463999950 " [12] -3511325491200000 " -3511325491200000 " [13] -3459303014399950 " -3459303014399950 " [14] -3392416972800000 " -3392416972800000 " [15] -3328008191999950 " -3328008191999950 " [16] -3262906368000000 " -3262906368000000 " [17] -3189664972799950 " -3189664972799950 " [18] -3123855360000000 " -3123855360000000 " [19] -3065801932799950 " -3065801932799950 " [20] -3003487027200000 " -3003487027200000 " [21] -2929523097599950 " -2929523097599950 " [22] -2875023360000000 " -2875023360000000 " [23] -2805660057599950 " -2805660057599950 " [24] -2746205798400000 " -2746205798400000 " [25] -2679319756799950 " -2679319756799950 " [26] -2617388236800000 " -2617388236800000 " [27] -1626498662399950 " -1626498662399950 " [28] -1584385228800000 " -1584385228800000 " [29] -1519976447999950 " -1519976447999950 " [30] -1455567667200000 " -1455567667200000 " [31] -1368863539199950 " -1368863539199950 " [32] -1324272844800000 " -1324272844800000 " [33] -1259864063999950 " -1259864063999950 " [34] -1195455283200000 " -1195455283200000 " [35] -1111228415999950 " -1111228415999950 " [36] -1066637721600000 " -1066637721600000 " [37] -982410854399950 " -982410854399950 " [38] -937820160000000 " -937820160000000 " [39] -853593292799950 " -853593292799950 " [40] -809002598400000 " -809002598400000 " [41] -722298470399950 " -722298470399950 " [42] -680185036800000 " -680185036800000 " [43] 937466265600050 " 937466265600050 " [44] 999397785600000 " 999397785600000 " [45] 1066283827200050 " 1066283827200050 " [46] 1130692608000000 " 1130692608000000 " [47] 1195101388800050 " 1195101388800050 " [48] 1259510169600000 " 1259510169600000 " [49] 1326396211200050 " 1326396211200050 " [50] 1388327731200000 " 1388327731200000 " [51] 1452736512000050 " 1452736512000050 " [52] 1517145292800000 " 1517145292800000 " [53] 1581554073600050 " 1581554073600050 " [54] 1645962854400000 " 1645962854400000 " [55] 1710371635200050 " 1710371635200050 " [56] 1774780416000000 " 1774780416000000 " [57] 1839189196800050 " 1839189196800050 " [58] 1906075238400000 " 1906075238400000 " [59] 1970484019200050 " 1970484019200050 " [60] 2034892800000000 " 2034892800000000 " [61] 2099301580800050 " 2099301580800050 " [62] 2163710361600000 " 2163710361600000 " [63] 2228119142400050 " 2228119142400050 " [64] 2292527923200000 " 2292527923200000 " [65] 2356951449600050 " 2356951449600050 " [66] 2421360230400000 " 2421360230400000 " [67] 2485769011200050 " 2485769011200050 " [68] 2550177792000000 " 2550177792000000 " [69] 2614586572800050 " 2614586572800050 " [70] 2681472614400000 " 2681472614400000 " [71] 2745881395200050 " 2745881395200050 " [72] 2810290176000000 " 2810290176000000 " [73] 2874698956800050 " 2874698956800050 " [74] 2939107737600000 " 2939107737600000 " [75] 3003516518400050 " 3003516518400050 " [76] 3067925299200000 " 3067925299200000 " [77] 3132334080000050 " 3132334080000050 " [78] 3196742860800000 " 3196742860800000 " [79] 3261151641600050 " 3261151641600050 " [80] 3325560422400000 " 3325560422400000 " [81] 3392446464000050 " 3392446464000050 " [82] 3466764288000000 " 3466764288000000 " [83] 3521264025600050 " 3521264025600050 " [84] 3595581849600000 " 3595581849600000 " [85] 3650081587200050 " 3650081587200050 " [86] 3724399411200000 " 3724399411200000 " [87] 3778899148800050 " 3778899148800050 " [88] 3855694233600000 " 3855694233600000 " [89] 3907716710400050 " 3907716710400050 " [90] 3984511795200000 " 3984511795200000 " [91] 4036534272000050 " 4036534272000050 " [92] 4113329356800000 " 4113329356800000 " [93] 4167829094400050 " 4167829094400050 " [94] 4242146918400000 " 4242146918400000 " [95] 4296646656000050 " 4296646656000050 " [96] 4370964480000000 " 4370964480000000 " [97] 4425464217600050 " 4425464217600050 " [98] 4502259302400000 " 4502259302400000 " [99] 4554281779200050 " 4554281779200050 " [100...164] " " [100] 4631076864000000 " 4631076864000000 " [101] 4683099340800050 " 4683099340800050 " [102] 4759894425600000 " 4759894425600000 " [103] 4811916902400050 " 4811916902400050 " [104] 4888711987200000 " 4888711987200000 " [105] 4943211724800050 " 4943211724800050 " [106] 5017529548800000 " 5017529548800000 " [107] 5072029286400050 " 5072029286400050 " [108] 5146347110400000 " 5146347110400000 " [109] 5200846848000050 " 5200846848000050 " [110] 5277641932800000 " 5277641932800000 " [111] 5329664409600050 " 5329664409600050 " [112] 5406459494400000 " 5406459494400000 " [113] 5458481971200050 " 5458481971200050 " [114] 5535277056000000 " 5535277056000000 " [115] 5589776793600050 " 5589776793600050 " [116] 5664094617600000 " 5664094617600000 " [117] 5718594355200050 " 5718594355200050 " [118] 5792912179200000 " 5792912179200000 " [119] 5847411916800050 " 5847411916800050 " [120] 5921729740800000 " 5921729740800000 " [121] 5976229478400050 " 5976229478400050 " [122] 6053024563200000 " 6053024563200000 " [123] 6105047040000050 " 6105047040000050 " [124] 6181842124800000 " 6181842124800000 " [125] 6233864601600050 " 6233864601600050 " [126] 6310659686400000 " 6310659686400000 " [127] 6365159424000050 " 6365159424000050 " [128] 6439477248000000 " 6439477248000000 " [129] 6493976985600050 " 6493976985600050 " [130] 6568294809600000 " 6568294809600000 " [131] 6622794547200050 " 6622794547200050 " [132] 6699589632000000 " 6699589632000000 " [133] 6751612108800050 " 6751612108800050 " [134] 6828407193600000 " 6828407193600000 " [135] 6880429670400050 " 6880429670400050 " [136] 6957224755200000 " 6957224755200000 " [137] 7011724492800050 " 7011724492800050 " [138] 7086042316800000 " 7086042316800000 " [139] 7140542054400050 " 7140542054400050 " [140] 7214859878400000 " 7214859878400000 " [141] 7269359616000050 " 7269359616000050 " [142] 7343677440000000 " 7343677440000000 " [143] 7398177177600050 " 7398177177600050 " [144] 7474972262400000 " 7474972262400000 " [145] 7526994739200050 " 7526994739200050 " [146] 7603789824000000 " 7603789824000000 " [147] 7655812300800050 " 7655812300800050 " [148] 7732607385600000 " 7732607385600000 " [149] 7787107123200050 " 7787107123200050 " [150] 7861424947200000 " 7861424947200000 " [151] 7915924684800050 " 7915924684800050 " [152] 7990242508800000 " 7990242508800000 " [153] 8044742246400050 " 8044742246400050 " [154] 8121537331200000 " 8121537331200000 " [155] 8173559808000050 " 8173559808000050 " [156] 8250354892800000 " 8250354892800000 " [157] 8302377369600050 " 8302377369600050 " [158] 8379172454400000 " 8379172454400000 " [159] 8431194931200050 " 8431194931200050 " [160] 8507990016000000 " 8507990016000000 " [161] 8562489753600050 " 8562489753600050 " [162] 8636807577600000 " 8636807577600000 " [163] 8691307315200050 " 8691307315200050 " [164] 8765625139200000 " 8765625139200000 " willGMTOffsetChange false " FALSE " zoneOffset 3600000 " 3600000 " fastTime 1416438000000 " 1416438000000 {code} After comparing them in diff viewer - the difference is only in first two lines: |"dataOd Date (id=72) "| Thu Nov 20 00:00:00 CET 2014 |"dataOd Date (id=123) "| 2014-11-20| |" cdate Gregorian$Date (id=82) "| 2014-11-20T00:00:00.000+0100 |" cdate Gregorian$Date (id=129) "| 2014-11-20T00:00:00.000+0100| in first line - toString and id, in second line - only id Why date in object read from cache (after creating in same session) has different toString than read from no cache - objects in debugger looks same, so I really don't know what is the problem was: 1. Configure sessionFactory in applicationContext.xml to use second level cache: {code:xml} ... true true org.hibernate.cache.ehcache.EhCacheRegionFactory {code} 2. Entities to save: cache version: {code:java} @Entity @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) @Table(name = "SLO_MKRAJEWSKI") public class CacheMkrajewski { private Long id; @Id @Column(name = "COLUMN2", nullable = false, precision = 10, scale = 0) @SequenceGenerator(name = "seq_mkrajewski", sequenceName = "seq_mkrajewski", allocationSize = 1) @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_mkrajewski") public Long getId() { return this.id; } public void setId(Long id) { this.id = id; } private Date dataOd; @Temporal(TemporalType.DATE) @Column(name = "COLUMN1") public Date getDataOd() { return this.dataOd; } public void setDataOd(Date dataOd) { this.dataOd = dataOd; } @Override public String toString() { return "CacheMkrajewski [id=" + this.id + ", dataOd=" + this.dataOd + "]"; } } {code} no cache version: {code:java} @Entity @Table(name = "SLO_MKRAJEWSKI") public class NoCacheMkrajewski { private Long id; @Id @Column(name = "COLUMN2", nullable = false, precision = 10, scale = 0) @SequenceGenerator(name = "seq_mkrajewski", sequenceName = "seq_mkrajewski", allocationSize = 1) @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_mkrajewski") public Long getId() { return this.id; } public void setId(Long id) { this.id = id; } private Date dataOd; @Temporal(TemporalType.DATE) @Column(name = "COLUMN1") public Date getDataOd() { return this.dataOd; } public void setDataOd(Date dataOd) { this.dataOd = dataOd; } @Override public String toString() { return "NoCacheMkrajewski [id=" + this.id + ", dataOd=" + this.dataOd + "]"; } } {code} you can see that difference is only in removing @Cache adnotation for no cache class definition 3. Injecting sessionFactory in DAO: {code:java} @Autowired private SessionFactory sessionFactory; private Session getSession() { return this.sessionFactory.getCurrentSession(); } {code} 4. Creating model in DAO: cache version {code:java} public void save(CacheMkrajewski model) { getSession().persist(model); } {code} or no cache version: {code:java} public void save(NoCacheMkrajewski model) { getSession().persist(model); } {code} same way 5. Loading model in DAO: cache version {code:java} public CacheMkrajewski loadCache(Long id) { return (CacheMkrajewski) getSession().get(CacheMkrajewski.class, id); } {code} no cache version {code:java} public NoCacheMkrajewski loadNoCache(Long id) { return (NoCacheMkrajewski) getSession().get(NoCacheMkrajewski.class, id); } {code} 6. Injection DAO in business layer: business interface {code:java} public interface ITestBusiness { CacheMkrajewski loadCache(Long id); void save(CacheMkrajewski model); NoCacheMkrajewski loadNoCache(Long id); void save(NoCacheMkrajewski model); } {code} Business impl {code:java} @Component @Transactional public class TestBusiness implements ITestBusiness { @Autowired private TestDao dao; @Override public CacheMkrajewski loadCache(Long id) { return this.dao.loadCache(id); } @Override public void save(CacheMkrajewski model) { this.dao.save(model); } @Override public NoCacheMkrajewski loadNoCache(Long id) { return this.dao.loadNoCache(id); } @Override public void save(NoCacheMkrajewski model) { this.dao.save(model); } } {code} 7. invoke JUnit {code:java} @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(locations = {"classpath:/mkrajewski/applicationContext-cache.xml" }) public class DateCacheTest { @Autowired private ITestBusiness testBusiness; @Before public void before() { } @Test public void cacheTest() { CacheMkrajewski cached = cacheEntity(); this.testBusiness.save(cached); cached = this.testBusiness.loadCache(cached.getId()); CacheMkrajewski loaded = this.testBusiness.loadCache(61L); System.out.println(); System.out.println("Cache " + cached); System.out.println("Loaded " + loaded); System.out.println(); } @Test public void noCacheTest() { NoCacheMkrajewski noCached = noCacheEntity(); this.testBusiness.save(noCached); noCached = this.testBusiness.loadNoCache(noCached.getId()); NoCacheMkrajewski loaded = this.testBusiness.loadNoCache(61L); System.out.println(); System.out.println("No cache " + noCached); System.out.println("Loaded " + loaded); System.out.println(); } private CacheMkrajewski cacheEntity() { CacheMkrajewski cache = new CacheMkrajewski(); cache.setDataOd(dateWithNoTime()); return cache; } private NoCacheMkrajewski noCacheEntity() { NoCacheMkrajewski noCache = new NoCacheMkrajewski(); noCache.setDataOd(dateWithNoTime()); return noCache; } private Date dateWithNoTime() { Calendar calendar = Calendar.getInstance(); calendar.clear(); calendar.set(Calendar.YEAR, 2014); calendar.set(Calendar.MONTH, 10); calendar.set(Calendar.DAY_OF_MONTH, 20); return calendar.getTime(); } } {code} we can assume that in database exists object with ID 61 8. Differences in System.outs - toString() difference: cache version {code} Cache CacheMkrajewski [id=130, dataOd=Thu Nov 20 00:00:00 CET 2014] Loaded CacheMkrajewski [id=61, dataOd=2014-11-20] {code} no cache version {code} No cache NoCacheMkrajewski [id=131, dataOd=2014-11-20] Loaded NoCacheMkrajewski [id=61, dataOd=2014-11-20] {code} When we read object created in the same session using second level cache - there is problem with date object. In new object minutes, seconds and CEST is added. When read object created in previous session (id 61) problem disappear. Problem does not exists if we use entity with disabled @Cache Full date objects from eclipse DEBUGGER: {code} CACHE OBJECT "dataOd Date (id=72) " Thu Nov 20 00:00:00 CET 2014 " cdate Gregorian$Date (id=82) " 2014-11-20T00:00:00.000+0100 " cachedFixedDateJan1 735234 " 735234 " cachedFixedDateNextJan1 735599 " 735599 " cachedYear 2014 " 2014 " daylightSaving 0 " 0 " dayOfMonth 20 " 20 " dayOfWeek 5 " 5 " era null " null " forceStandardTime false " FALSE " fraction 0 " 0 " hours 0 " 0 " leapYear false " FALSE " locale null " null " millis 0 " 0 " minutes 0 " 0 " month 11 " 11 " normalized true " TRUE " seconds 0 " 0 " year 2014 " 2014 " zoneinfo ZoneInfo (id=86) " sun.util.calendar.ZoneInfo[id="Europe/Warsaw",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=165,lastRule=java.util.SimpleTimeZone[id=Europe/Warsaw,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]] " checksum -1578751392 " -1578751392 " dirty false " FALSE " dstSavings 3600000 " 3600000 " ID ""Europe/Warsaw"" (id=92) " Europe/Warsaw " count 13 " 13 " hash 826225934 " 826225934 " offset 0 " 0 " value (id=100) " [E, u, r, o, p, e, /, W, a, r, s, a, w] " [0] E " E " [1] u " u " [2] r " r " [3] o " o " [4] p " p " [5] e " e " [6] / " / " [7] W " W " [8] a " a " [9] r " r " [10] s " s " [11] a " a " [12] w " w " lastRule null " null " offsets (id=95) " [3600000, 5040000, 7200000, 3600000, 10800000] " [0] 3600000 " 3600000 " [1] 5040000 " 5040000 " [2] 7200000 " 7200000 " [3] 3600000 " 3600000 " [4] 10800000 " 10800000 " rawOffset 3600000 " 3600000 " rawOffsetDiff 0 " 0 " simpleTimeZoneParams (id=97) " [2, -1, 1, 3600000, 2, 9, -1, 1, 3600000, 2] " [0] 2 " 2 " [1] -1 " -1 " [2] 1 " 1 " [3] 3600000 " 3600000 " [4] 2 " 2 " [5] 9 " 9 " [6] -1 " -1 " [7] 1 " 1 " [8] 3600000 " 3600000 " [9] 2 " 2 " transitions (id=98) " [-9048018124799999, -7032964055040000, -6937421414399950, -6883260825600000, -6813514137599950, -6759014400000000, -6684696575999950, -6630196838399998, -6555539865599948, -6501040127999998, -6151068057600000, -3816382463999950, -3511325491200000, -3459303014399950, -3392416972800000, -3328008191999950, -3262906368000000, -3189664972799950, -3123855360000000, -3065801932799950, -3003487027200000, -2929523097599950, -2875023360000000, -2805660057599950, -2746205798400000, -2679319756799950, -2617388236800000, -1626498662399950, -1584385228800000, -1519976447999950, -1455567667200000, -1368863539199950, -1324272844800000, -1259864063999950, -1195455283200000, -1111228415999950, -1066637721600000, -982410854399950, -937820160000000, -853593292799950, -809002598400000, -722298470399950, -680185036800000, 937466265600050, 999397785600000, 1066283827200050, 1130692608000000, 1195101388800050, 1259510169600000, 1326396211200050, 1388327731200000, 1452736512000050, 1517145292800000, 1581554073600050, 1645962854400000, 1710371635200050, 1774780416000000, 1839189196800050, 1906075238400000, 1970484019200050, 2034892800000000, 2099301580800050, 2163710361600000, 2228119142400050, 2292527923200000, 2356951449600050, 2421360230400000, 2485769011200050, 2550177792000000, 2614586572800050, 2681472614400000, 2745881395200050, 2810290176000000, 2874698956800050, 2939107737600000, 3003516518400050, 3067925299200000, 3132334080000050, 3196742860800000, 3261151641600050, 3325560422400000, 3392446464000050, 3466764288000000, 3521264025600050, 3595581849600000, 3650081587200050, 3724399411200000, 3778899148800050, 3855694233600000, 3907716710400050, 3984511795200000, 4036534272000050, 4113329356800000, 4167829094400050, 4242146918400000, 4296646656000050, 4370964480000000, 4425464217600050, 4502259302400000, 4554281779200050, 4631076864000000, 4683099340800050, 4759894425600000, 4811916902400050, 4888711987200000, 4943211724800050, 5017529548800000, 5072029286400050, 5146347110400000, 5200846848000050, 5277641932800000, 5329664409600050, 5406459494400000, 5458481971200050, 5535277056000000, 5589776793600050, 5664094617600000, 5718594355200050, 5792912179200000, 5847411916800050, 5921729740800000, 5976229478400050, 6053024563200000, 6105047040000050, 6181842124800000, 6233864601600050, 6310659686400000, 6365159424000050, 6439477248000000, 6493976985600050, 6568294809600000, 6622794547200050, 6699589632000000, 6751612108800050, 6828407193600000, 6880429670400050, 6957224755200000, 7011724492800050, 7086042316800000, 7140542054400050, 7214859878400000, 7269359616000050, 7343677440000000, 7398177177600050, 7474972262400000, 7526994739200050, 7603789824000000, 7655812300800050, 7732607385600000, 7787107123200050, 7861424947200000, 7915924684800050, 7990242508800000, 8044742246400050, 8121537331200000, 8173559808000050, 8250354892800000, 8302377369600050, 8379172454400000, 8431194931200050, 8507990016000000, 8562489753600050, 8636807577600000, 8691307315200050, 8765625139200000] " [0...99] " " [0] -9048018124799999 " -9048018124800000 " [1] -7032964055040000 " -7032964055040000 " [2] -6937421414399950 " -6937421414399950 " [3] -6883260825600000 " -6883260825600000 " [4] -6813514137599950 " -6813514137599950 " [5] -6759014400000000 " -6759014400000000 " [6] -6684696575999950 " -6684696575999950 " [7] -6630196838399998 " -6630196838400000 " [8] -6555539865599948 " -6555539865599950 " [9] -6501040127999998 " -6501040128000000 " [10] -6151068057600000 " -6151068057600000 " [11] -3816382463999950 " -3816382463999950 " [12] -3511325491200000 " -3511325491200000 " [13] -3459303014399950 " -3459303014399950 " [14] -3392416972800000 " -3392416972800000 " [15] -3328008191999950 " -3328008191999950 " [16] -3262906368000000 " -3262906368000000 " [17] -3189664972799950 " -3189664972799950 " [18] -3123855360000000 " -3123855360000000 " [19] -3065801932799950 " -3065801932799950 " [20] -3003487027200000 " -3003487027200000 " [21] -2929523097599950 " -2929523097599950 " [22] -2875023360000000 " -2875023360000000 " [23] -2805660057599950 " -2805660057599950 " [24] -2746205798400000 " -2746205798400000 " [25] -2679319756799950 " -2679319756799950 " [26] -2617388236800000 " -2617388236800000 " [27] -1626498662399950 " -1626498662399950 " [28] -1584385228800000 " -1584385228800000 " [29] -1519976447999950 " -1519976447999950 " [30] -1455567667200000 " -1455567667200000 " [31] -1368863539199950 " -1368863539199950 " [32] -1324272844800000 " -1324272844800000 " [33] -1259864063999950 " -1259864063999950 " [34] -1195455283200000 " -1195455283200000 " [35] -1111228415999950 " -1111228415999950 " [36] -1066637721600000 " -1066637721600000 " [37] -982410854399950 " -982410854399950 " [38] -937820160000000 " -937820160000000 " [39] -853593292799950 " -853593292799950 " [40] -809002598400000 " -809002598400000 " [41] -722298470399950 " -722298470399950 " [42] -680185036800000 " -680185036800000 " [43] 937466265600050 " 937466265600050 " [44] 999397785600000 " 999397785600000 " [45] 1066283827200050 " 1066283827200050 " [46] 1130692608000000 " 1130692608000000 " [47] 1195101388800050 " 1195101388800050 " [48] 1259510169600000 " 1259510169600000 " [49] 1326396211200050 " 1326396211200050 " [50] 1388327731200000 " 1388327731200000 " [51] 1452736512000050 " 1452736512000050 " [52] 1517145292800000 " 1517145292800000 " [53] 1581554073600050 " 1581554073600050 " [54] 1645962854400000 " 1645962854400000 " [55] 1710371635200050 " 1710371635200050 " [56] 1774780416000000 " 1774780416000000 " [57] 1839189196800050 " 1839189196800050 " [58] 1906075238400000 " 1906075238400000 " [59] 1970484019200050 " 1970484019200050 " [60] 2034892800000000 " 2034892800000000 " [61] 2099301580800050 " 2099301580800050 " [62] 2163710361600000 " 2163710361600000 " [63] 2228119142400050 " 2228119142400050 " [64] 2292527923200000 " 2292527923200000 " [65] 2356951449600050 " 2356951449600050 " [66] 2421360230400000 " 2421360230400000 " [67] 2485769011200050 " 2485769011200050 " [68] 2550177792000000 " 2550177792000000 " [69] 2614586572800050 " 2614586572800050 " [70] 2681472614400000 " 2681472614400000 " [71] 2745881395200050 " 2745881395200050 " [72] 2810290176000000 " 2810290176000000 " [73] 2874698956800050 " 2874698956800050 " [74] 2939107737600000 " 2939107737600000 " [75] 3003516518400050 " 3003516518400050 " [76] 3067925299200000 " 3067925299200000 " [77] 3132334080000050 " 3132334080000050 " [78] 3196742860800000 " 3196742860800000 " [79] 3261151641600050 " 3261151641600050 " [80] 3325560422400000 " 3325560422400000 " [81] 3392446464000050 " 3392446464000050 " [82] 3466764288000000 " 3466764288000000 " [83] 3521264025600050 " 3521264025600050 " [84] 3595581849600000 " 3595581849600000 " [85] 3650081587200050 " 3650081587200050 " [86] 3724399411200000 " 3724399411200000 " [87] 3778899148800050 " 3778899148800050 " [88] 3855694233600000 " 3855694233600000 " [89] 3907716710400050 " 3907716710400050 " [90] 3984511795200000 " 3984511795200000 " [91] 4036534272000050 " 4036534272000050 " [92] 4113329356800000 " 4113329356800000 " [93] 4167829094400050 " 4167829094400050 " [94] 4242146918400000 " 4242146918400000 " [95] 4296646656000050 " 4296646656000050 " [96] 4370964480000000 " 4370964480000000 " [97] 4425464217600050 " 4425464217600050 " [98] 4502259302400000 " 4502259302400000 " [99] 4554281779200050 " 4554281779200050 " [100...164] " " [100] 4631076864000000 " 4631076864000000 " [101] 4683099340800050 " 4683099340800050 " [102] 4759894425600000 " 4759894425600000 " [103] 4811916902400050 " 4811916902400050 " [104] 4888711987200000 " 4888711987200000 " [105] 4943211724800050 " 4943211724800050 " [106] 5017529548800000 " 5017529548800000 " [107] 5072029286400050 " 5072029286400050 " [108] 5146347110400000 " 5146347110400000 " [109] 5200846848000050 " 5200846848000050 " [110] 5277641932800000 " 5277641932800000 " [111] 5329664409600050 " 5329664409600050 " [112] 5406459494400000 " 5406459494400000 " [113] 5458481971200050 " 5458481971200050 " [114] 5535277056000000 " 5535277056000000 " [115] 5589776793600050 " 5589776793600050 " [116] 5664094617600000 " 5664094617600000 " [117] 5718594355200050 " 5718594355200050 " [118] 5792912179200000 " 5792912179200000 " [119] 5847411916800050 " 5847411916800050 " [120] 5921729740800000 " 5921729740800000 " [121] 5976229478400050 " 5976229478400050 " [122] 6053024563200000 " 6053024563200000 " [123] 6105047040000050 " 6105047040000050 " [124] 6181842124800000 " 6181842124800000 " [125] 6233864601600050 " 6233864601600050 " [126] 6310659686400000 " 6310659686400000 " [127] 6365159424000050 " 6365159424000050 " [128] 6439477248000000 " 6439477248000000 " [129] 6493976985600050 " 6493976985600050 " [130] 6568294809600000 " 6568294809600000 " [131] 6622794547200050 " 6622794547200050 " [132] 6699589632000000 " 6699589632000000 " [133] 6751612108800050 " 6751612108800050 " [134] 6828407193600000 " 6828407193600000 " [135] 6880429670400050 " 6880429670400050 " [136] 6957224755200000 " 6957224755200000 " [137] 7011724492800050 " 7011724492800050 " [138] 7086042316800000 " 7086042316800000 " [139] 7140542054400050 " 7140542054400050 " [140] 7214859878400000 " 7214859878400000 " [141] 7269359616000050 " 7269359616000050 " [142] 7343677440000000 " 7343677440000000 " [143] 7398177177600050 " 7398177177600050 " [144] 7474972262400000 " 7474972262400000 " [145] 7526994739200050 " 7526994739200050 " [146] 7603789824000000 " 7603789824000000 " [147] 7655812300800050 " 7655812300800050 " [148] 7732607385600000 " 7732607385600000 " [149] 7787107123200050 " 7787107123200050 " [150] 7861424947200000 " 7861424947200000 " [151] 7915924684800050 " 7915924684800050 " [152] 7990242508800000 " 7990242508800000 " [153] 8044742246400050 " 8044742246400050 " [154] 8121537331200000 " 8121537331200000 " [155] 8173559808000050 " 8173559808000050 " [156] 8250354892800000 " 8250354892800000 " [157] 8302377369600050 " 8302377369600050 " [158] 8379172454400000 " 8379172454400000 " [159] 8431194931200050 " 8431194931200050 " [160] 8507990016000000 " 8507990016000000 " [161] 8562489753600050 " 8562489753600050 " [162] 8636807577600000 " 8636807577600000 " [163] 8691307315200050 " 8691307315200050 " [164] 8765625139200000 " 8765625139200000 " willGMTOffsetChange false " FALSE " zoneOffset 3600000 " 3600000 " fastTime 1416438000000 " 1416438000000 {code} {code} NO CACHE OBJECT "dataOd Date (id=123) " 2014-11-20 " cdate Gregorian$Date (id=129) " 2014-11-20T00:00:00.000+0100 " cachedFixedDateJan1 735234 " 735234 " cachedFixedDateNextJan1 735599 " 735599 " cachedYear 2014 " 2014 " daylightSaving 0 " 0 " dayOfMonth 20 " 20 " dayOfWeek 5 " 5 " era null " null " forceStandardTime false " FALSE " fraction 0 " 0 " hours 0 " 0 " leapYear false " FALSE " locale null " null " millis 0 " 0 " minutes 0 " 0 " month 11 " 11 " normalized true " TRUE " seconds 0 " 0 " year 2014 " 2014 " zoneinfo ZoneInfo (id=86) " sun.util.calendar.ZoneInfo[id="Europe/Warsaw",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=165,lastRule=java.util.SimpleTimeZone[id=Europe/Warsaw,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]] " checksum -1578751392 " -1578751392 " dirty false " FALSE " dstSavings 3600000 " 3600000 " ID ""Europe/Warsaw"" (id=92) " Europe/Warsaw " count 13 " 13 " hash 826225934 " 826225934 " offset 0 " 0 " value (id=100) " [E, u, r, o, p, e, /, W, a, r, s, a, w] " [0] E " E " [1] u " u " [2] r " r " [3] o " o " [4] p " p " [5] e " e " [6] / " / " [7] W " W " [8] a " a " [9] r " r " [10] s " s " [11] a " a " [12] w " w " lastRule null " null " offsets (id=95) " [3600000, 5040000, 7200000, 3600000, 10800000] " [0] 3600000 " 3600000 " [1] 5040000 " 5040000 " [2] 7200000 " 7200000 " [3] 3600000 " 3600000 " [4] 10800000 " 10800000 " rawOffset 3600000 " 3600000 " rawOffsetDiff 0 " 0 " simpleTimeZoneParams (id=97) " [2, -1, 1, 3600000, 2, 9, -1, 1, 3600000, 2] " [0] 2 " 2 " [1] -1 " -1 " [2] 1 " 1 " [3] 3600000 " 3600000 " [4] 2 " 2 " [5] 9 " 9 " [6] -1 " -1 " [7] 1 " 1 " [8] 3600000 " 3600000 " [9] 2 " 2 " transitions (id=98) " [-9048018124799999, -7032964055040000, -6937421414399950, -6883260825600000, -6813514137599950, -6759014400000000, -6684696575999950, -6630196838399998, -6555539865599948, -6501040127999998, -6151068057600000, -3816382463999950, -3511325491200000, -3459303014399950, -3392416972800000, -3328008191999950, -3262906368000000, -3189664972799950, -3123855360000000, -3065801932799950, -3003487027200000, -2929523097599950, -2875023360000000, -2805660057599950, -2746205798400000, -2679319756799950, -2617388236800000, -1626498662399950, -1584385228800000, -1519976447999950, -1455567667200000, -1368863539199950, -1324272844800000, -1259864063999950, -1195455283200000, -1111228415999950, -1066637721600000, -982410854399950, -937820160000000, -853593292799950, -809002598400000, -722298470399950, -680185036800000, 937466265600050, 999397785600000, 1066283827200050, 1130692608000000, 1195101388800050, 1259510169600000, 1326396211200050, 1388327731200000, 1452736512000050, 1517145292800000, 1581554073600050, 1645962854400000, 1710371635200050, 1774780416000000, 1839189196800050, 1906075238400000, 1970484019200050, 2034892800000000, 2099301580800050, 2163710361600000, 2228119142400050, 2292527923200000, 2356951449600050, 2421360230400000, 2485769011200050, 2550177792000000, 2614586572800050, 2681472614400000, 2745881395200050, 2810290176000000, 2874698956800050, 2939107737600000, 3003516518400050, 3067925299200000, 3132334080000050, 3196742860800000, 3261151641600050, 3325560422400000, 3392446464000050, 3466764288000000, 3521264025600050, 3595581849600000, 3650081587200050, 3724399411200000, 3778899148800050, 3855694233600000, 3907716710400050, 3984511795200000, 4036534272000050, 4113329356800000, 4167829094400050, 4242146918400000, 4296646656000050, 4370964480000000, 4425464217600050, 4502259302400000, 4554281779200050, 4631076864000000, 4683099340800050, 4759894425600000, 4811916902400050, 4888711987200000, 4943211724800050, 5017529548800000, 5072029286400050, 5146347110400000, 5200846848000050, 5277641932800000, 5329664409600050, 5406459494400000, 5458481971200050, 5535277056000000, 5589776793600050, 5664094617600000, 5718594355200050, 5792912179200000, 5847411916800050, 5921729740800000, 5976229478400050, 6053024563200000, 6105047040000050, 6181842124800000, 6233864601600050, 6310659686400000, 6365159424000050, 6439477248000000, 6493976985600050, 6568294809600000, 6622794547200050, 6699589632000000, 6751612108800050, 6828407193600000, 6880429670400050, 6957224755200000, 7011724492800050, 7086042316800000, 7140542054400050, 7214859878400000, 7269359616000050, 7343677440000000, 7398177177600050, 7474972262400000, 7526994739200050, 7603789824000000, 7655812300800050, 7732607385600000, 7787107123200050, 7861424947200000, 7915924684800050, 7990242508800000, 8044742246400050, 8121537331200000, 8173559808000050, 8250354892800000, 8302377369600050, 8379172454400000, 8431194931200050, 8507990016000000, 8562489753600050, 8636807577600000, 8691307315200050, 8765625139200000] " [0...99] " " [0] -9048018124799999 " -9048018124800000 " [1] -7032964055040000 " -7032964055040000 " [2] -6937421414399950 " -6937421414399950 " [3] -6883260825600000 " -6883260825600000 " [4] -6813514137599950 " -6813514137599950 " [5] -6759014400000000 " -6759014400000000 " [6] -6684696575999950 " -6684696575999950 " [7] -6630196838399998 " -6630196838400000 " [8] -6555539865599948 " -6555539865599950 " [9] -6501040127999998 " -6501040128000000 " [10] -6151068057600000 " -6151068057600000 " [11] -3816382463999950 " -3816382463999950 " [12] -3511325491200000 " -3511325491200000 " [13] -3459303014399950 " -3459303014399950 " [14] -3392416972800000 " -3392416972800000 " [15] -3328008191999950 " -3328008191999950 " [16] -3262906368000000 " -3262906368000000 " [17] -3189664972799950 " -3189664972799950 " [18] -3123855360000000 " -3123855360000000 " [19] -3065801932799950 " -3065801932799950 " [20] -3003487027200000 " -3003487027200000 " [21] -2929523097599950 " -2929523097599950 " [22] -2875023360000000 " -2875023360000000 " [23] -2805660057599950 " -2805660057599950 " [24] -2746205798400000 " -2746205798400000 " [25] -2679319756799950 " -2679319756799950 " [26] -2617388236800000 " -2617388236800000 " [27] -1626498662399950 " -1626498662399950 " [28] -1584385228800000 " -1584385228800000 " [29] -1519976447999950 " -1519976447999950 " [30] -1455567667200000 " -1455567667200000 " [31] -1368863539199950 " -1368863539199950 " [32] -1324272844800000 " -1324272844800000 " [33] -1259864063999950 " -1259864063999950 " [34] -1195455283200000 " -1195455283200000 " [35] -1111228415999950 " -1111228415999950 " [36] -1066637721600000 " -1066637721600000 " [37] -982410854399950 " -982410854399950 " [38] -937820160000000 " -937820160000000 " [39] -853593292799950 " -853593292799950 " [40] -809002598400000 " -809002598400000 " [41] -722298470399950 " -722298470399950 " [42] -680185036800000 " -680185036800000 " [43] 937466265600050 " 937466265600050 " [44] 999397785600000 " 999397785600000 " [45] 1066283827200050 " 1066283827200050 " [46] 1130692608000000 " 1130692608000000 " [47] 1195101388800050 " 1195101388800050 " [48] 1259510169600000 " 1259510169600000 " [49] 1326396211200050 " 1326396211200050 " [50] 1388327731200000 " 1388327731200000 " [51] 1452736512000050 " 1452736512000050 " [52] 1517145292800000 " 1517145292800000 " [53] 1581554073600050 " 1581554073600050 " [54] 1645962854400000 " 1645962854400000 " [55] 1710371635200050 " 1710371635200050 " [56] 1774780416000000 " 1774780416000000 " [57] 1839189196800050 " 1839189196800050 " [58] 1906075238400000 " 1906075238400000 " [59] 1970484019200050 " 1970484019200050 " [60] 2034892800000000 " 2034892800000000 " [61] 2099301580800050 " 2099301580800050 " [62] 2163710361600000 " 2163710361600000 " [63] 2228119142400050 " 2228119142400050 " [64] 2292527923200000 " 2292527923200000 " [65] 2356951449600050 " 2356951449600050 " [66] 2421360230400000 " 2421360230400000 " [67] 2485769011200050 " 2485769011200050 " [68] 2550177792000000 " 2550177792000000 " [69] 2614586572800050 " 2614586572800050 " [70] 2681472614400000 " 2681472614400000 " [71] 2745881395200050 " 2745881395200050 " [72] 2810290176000000 " 2810290176000000 " [73] 2874698956800050 " 2874698956800050 " [74] 2939107737600000 " 2939107737600000 " [75] 3003516518400050 " 3003516518400050 " [76] 3067925299200000 " 3067925299200000 " [77] 3132334080000050 " 3132334080000050 " [78] 3196742860800000 " 3196742860800000 " [79] 3261151641600050 " 3261151641600050 " [80] 3325560422400000 " 3325560422400000 " [81] 3392446464000050 " 3392446464000050 " [82] 3466764288000000 " 3466764288000000 " [83] 3521264025600050 " 3521264025600050 " [84] 3595581849600000 " 3595581849600000 " [85] 3650081587200050 " 3650081587200050 " [86] 3724399411200000 " 3724399411200000 " [87] 3778899148800050 " 3778899148800050 " [88] 3855694233600000 " 3855694233600000 " [89] 3907716710400050 " 3907716710400050 " [90] 3984511795200000 " 3984511795200000 " [91] 4036534272000050 " 4036534272000050 " [92] 4113329356800000 " 4113329356800000 " [93] 4167829094400050 " 4167829094400050 " [94] 4242146918400000 " 4242146918400000 " [95] 4296646656000050 " 4296646656000050 " [96] 4370964480000000 " 4370964480000000 " [97] 4425464217600050 " 4425464217600050 " [98] 4502259302400000 " 4502259302400000 " [99] 4554281779200050 " 4554281779200050 " [100...164] " " [100] 4631076864000000 " 4631076864000000 " [101] 4683099340800050 " 4683099340800050 " [102] 4759894425600000 " 4759894425600000 " [103] 4811916902400050 " 4811916902400050 " [104] 4888711987200000 " 4888711987200000 " [105] 4943211724800050 " 4943211724800050 " [106] 5017529548800000 " 5017529548800000 " [107] 5072029286400050 " 5072029286400050 " [108] 5146347110400000 " 5146347110400000 " [109] 5200846848000050 " 5200846848000050 " [110] 5277641932800000 " 5277641932800000 " [111] 5329664409600050 " 5329664409600050 " [112] 5406459494400000 " 5406459494400000 " [113] 5458481971200050 " 5458481971200050 " [114] 5535277056000000 " 5535277056000000 " [115] 5589776793600050 " 5589776793600050 " [116] 5664094617600000 " 5664094617600000 " [117] 5718594355200050 " 5718594355200050 " [118] 5792912179200000 " 5792912179200000 " [119] 5847411916800050 " 5847411916800050 " [120] 5921729740800000 " 5921729740800000 " [121] 5976229478400050 " 5976229478400050 " [122] 6053024563200000 " 6053024563200000 " [123] 6105047040000050 " 6105047040000050 " [124] 6181842124800000 " 6181842124800000 " [125] 6233864601600050 " 6233864601600050 " [126] 6310659686400000 " 6310659686400000 " [127] 6365159424000050 " 6365159424000050 " [128] 6439477248000000 " 6439477248000000 " [129] 6493976985600050 " 6493976985600050 " [130] 6568294809600000 " 6568294809600000 " [131] 6622794547200050 " 6622794547200050 " [132] 6699589632000000 " 6699589632000000 " [133] 6751612108800050 " 6751612108800050 " [134] 6828407193600000 " 6828407193600000 " [135] 6880429670400050 " 6880429670400050 " [136] 6957224755200000 " 6957224755200000 " [137] 7011724492800050 " 7011724492800050 " [138] 7086042316800000 " 7086042316800000 " [139] 7140542054400050 " 7140542054400050 " [140] 7214859878400000 " 7214859878400000 " [141] 7269359616000050 " 7269359616000050 " [142] 7343677440000000 " 7343677440000000 " [143] 7398177177600050 " 7398177177600050 " [144] 7474972262400000 " 7474972262400000 " [145] 7526994739200050 " 7526994739200050 " [146] 7603789824000000 " 7603789824000000 " [147] 7655812300800050 " 7655812300800050 " [148] 7732607385600000 " 7732607385600000 " [149] 7787107123200050 " 7787107123200050 " [150] 7861424947200000 " 7861424947200000 " [151] 7915924684800050 " 7915924684800050 " [152] 7990242508800000 " 7990242508800000 " [153] 8044742246400050 " 8044742246400050 " [154] 8121537331200000 " 8121537331200000 " [155] 8173559808000050 " 8173559808000050 " [156] 8250354892800000 " 8250354892800000 " [157] 8302377369600050 " 8302377369600050 " [158] 8379172454400000 " 8379172454400000 " [159] 8431194931200050 " 8431194931200050 " [160] 8507990016000000 " 8507990016000000 " [161] 8562489753600050 " 8562489753600050 " [162] 8636807577600000 " 8636807577600000 " [163] 8691307315200050 " 8691307315200050 " [164] 8765625139200000 " 8765625139200000 " willGMTOffsetChange false " FALSE " zoneOffset 3600000 " 3600000 " fastTime 1416438000000 " 1416438000000 {code} After comparing them in diff viewer - the difference is only in first two lines: |"dataOd Date (id=72) "| Thu Nov 20 00:00:00 CET 2014 |"dataOd Date (id=123) "| 2014-11-20| |" cdate Gregorian$Date (id=82) "| 2014-11-20T00:00:00.000+0100 |" cdate Gregorian$Date (id=129) "| 2014-11-20T00:00:00.000+0100| in first line - toString and id, in second line - only id Why date in object read from cache (after creating in same session) has different toString than read from no cache - objects in debugger looks same, so I really don't know what is the problem > Second level cache - load object after create in same session - incorrect date > ------------------------------------------------------------------------------ > > Key: HIBERNATE-149 > URL: https://issues.jboss.org/browse/HIBERNATE-149 > Project: Hibernate Integration > Issue Type: Bug > Environment: Spring 4.1.0.RC2, Hibernate 4.3.6.Final > Reporter: Marcin Krajewski > Assignee: Steve Ebersole > > 1. Configure sessionFactory in applicationContext.xml to use second level cache: > {code:xml} > class="org.springframework.orm.hibernate4.LocalSessionFactoryBean"> > > > > > ... > true > true > org.hibernate.cache.ehcache.EhCacheRegionFactory > > > > {code} > 2. Entities to save: > cache version: > {code:java} > @Entity > @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) > @Table(name = "SLO_MKRAJEWSKI") > public class CacheMkrajewski { > private Long id; > @Id > @Column(name = "COLUMN2", nullable = false, precision = 10, scale = 0) > @SequenceGenerator(name = "seq_mkrajewski", sequenceName = "seq_mkrajewski", allocationSize = 1) > @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_mkrajewski") > public Long getId() { > return this.id; > } > public void setId(Long id) { > this.id = id; > } > private Date dataOd; > @Temporal(TemporalType.DATE) > @Column(name = "COLUMN1") > public Date getDataOd() { > return this.dataOd; > } > public void setDataOd(Date dataOd) { > this.dataOd = dataOd; > } > @Override > public String toString() { > return "CacheMkrajewski [id=" + this.id + ", dataOd=" + this.dataOd + "]"; > } > } > {code} > no cache version: > {code:java} > @Entity > @Table(name = "SLO_MKRAJEWSKI") > public class NoCacheMkrajewski { > private Long id; > @Id > @Column(name = "COLUMN2", nullable = false, precision = 10, scale = 0) > @SequenceGenerator(name = "seq_mkrajewski", sequenceName = "seq_mkrajewski", allocationSize = 1) > @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_mkrajewski") > public Long getId() { > return this.id; > } > public void setId(Long id) { > this.id = id; > } > private Date dataOd; > @Temporal(TemporalType.DATE) > @Column(name = "COLUMN1") > public Date getDataOd() { > return this.dataOd; > } > public void setDataOd(Date dataOd) { > this.dataOd = dataOd; > } > @Override > public String toString() { > return "NoCacheMkrajewski [id=" + this.id + ", dataOd=" + this.dataOd + "]"; > } > } > {code} > you can see that difference is only in removing @Cache adnotation for no cache class definition > 3. Injecting sessionFactory in DAO: > {code:java} > @Autowired > private SessionFactory sessionFactory; > private Session getSession() { > return this.sessionFactory.getCurrentSession(); > } > {code} > 4. Creating model in DAO: > cache version > {code:java} > public void save(CacheMkrajewski model) { > getSession().persist(model); > } > {code} > or no cache version: > {code:java} > public void save(NoCacheMkrajewski model) { > getSession().persist(model); > } > {code} > same way > 5. Loading model in DAO: > cache version > {code:java} > public CacheMkrajewski loadCache(Long id) { > return (CacheMkrajewski) getSession().get(CacheMkrajewski.class, id); > } > {code} > no cache version > {code:java} > public NoCacheMkrajewski loadNoCache(Long id) { > return (NoCacheMkrajewski) getSession().get(NoCacheMkrajewski.class, id); > } > {code} > 6. Injection DAO in business layer: > business interface > {code:java} > public interface ITestBusiness { > CacheMkrajewski loadCache(Long id); > void save(CacheMkrajewski model); > NoCacheMkrajewski loadNoCache(Long id); > void save(NoCacheMkrajewski model); > } > {code} > Business impl > {code:java} > @Component > @Transactional > public class TestBusiness implements ITestBusiness { > @Autowired > private TestDao dao; > @Override > public CacheMkrajewski loadCache(Long id) { > return this.dao.loadCache(id); > } > @Override > public void save(CacheMkrajewski model) { > this.dao.save(model); > } > @Override > public NoCacheMkrajewski loadNoCache(Long id) { > return this.dao.loadNoCache(id); > } > @Override > public void save(NoCacheMkrajewski model) { > this.dao.save(model); > } > } > {code} > 7. invoke JUnit > {code:java} > @RunWith(SpringJUnit4ClassRunner.class) > @ContextConfiguration(locations = {"classpath:/mkrajewski/applicationContext-cache.xml" }) > public class DateCacheTest { > @Autowired > private ITestBusiness testBusiness; > @Before > public void before() { > } > @Test > public void cacheTest() { > CacheMkrajewski cached = cacheEntity(); > this.testBusiness.save(cached); > cached = this.testBusiness.loadCache(cached.getId()); > CacheMkrajewski loaded = this.testBusiness.loadCache(61L); > System.out.println(); > System.out.println("Cache " + cached); > System.out.println("Loaded " + loaded); > System.out.println(); > } > @Test > public void noCacheTest() { > NoCacheMkrajewski noCached = noCacheEntity(); > this.testBusiness.save(noCached); > noCached = this.testBusiness.loadNoCache(noCached.getId()); > NoCacheMkrajewski loaded = this.testBusiness.loadNoCache(61L); > System.out.println(); > System.out.println("No cache " + noCached); > System.out.println("Loaded " + loaded); > System.out.println(); > } > private CacheMkrajewski cacheEntity() { > CacheMkrajewski cache = new CacheMkrajewski(); > cache.setDataOd(dateWithNoTime()); > return cache; > } > private NoCacheMkrajewski noCacheEntity() { > NoCacheMkrajewski noCache = new NoCacheMkrajewski(); > noCache.setDataOd(dateWithNoTime()); > return noCache; > } > private Date dateWithNoTime() { > Calendar calendar = Calendar.getInstance(); > calendar.clear(); > calendar.set(Calendar.YEAR, 2014); > calendar.set(Calendar.MONTH, 10); > calendar.set(Calendar.DAY_OF_MONTH, 20); > return calendar.getTime(); > } > } > {code} > we can assume that in database exists object with ID 61 > 8. Differences in System.outs - toString() difference: > cache version > {code} > Cache CacheMkrajewski [id=130, dataOd=Thu Nov 20 00:00:00 CET 2014] > Loaded CacheMkrajewski [id=61, dataOd=2014-11-20] > {code} > no cache version > {code} > No cache NoCacheMkrajewski [id=131, dataOd=2014-11-20] > Loaded NoCacheMkrajewski [id=61, dataOd=2014-11-20] > {code} > When we read object created in the same session using second level cache - there is problem with date object. In new object minutes, seconds and CEST is added. When read object created in previous session (id 61) problem disappear. > Problem does not exists if we use entity with disabled @Cache > 9. Full date objects from eclipse DEBUGGER: > {code} > CACHE OBJECT > "dataOd Date (id=72) " Thu Nov 20 00:00:00 CET 2014 > " cdate Gregorian$Date (id=82) " 2014-11-20T00:00:00.000+0100 > " cachedFixedDateJan1 735234 " 735234 > " cachedFixedDateNextJan1 735599 " 735599 > " cachedYear 2014 " 2014 > " daylightSaving 0 " 0 > " dayOfMonth 20 " 20 > " dayOfWeek 5 " 5 > " era null " null > " forceStandardTime false " FALSE > " fraction 0 " 0 > " hours 0 " 0 > " leapYear false " FALSE > " locale null " null > " millis 0 " 0 > " minutes 0 " 0 > " month 11 " 11 > " normalized true " TRUE > " seconds 0 " 0 > " year 2014 " 2014 > " zoneinfo ZoneInfo (id=86) " sun.util.calendar.ZoneInfo[id="Europe/Warsaw",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=165,lastRule=java.util.SimpleTimeZone[id=Europe/Warsaw,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]] > " checksum -1578751392 " -1578751392 > " dirty false " FALSE > " dstSavings 3600000 " 3600000 > " ID ""Europe/Warsaw"" (id=92) " Europe/Warsaw > " count 13 " 13 > " hash 826225934 " 826225934 > " offset 0 " 0 > " value (id=100) " [E, u, r, o, p, e, /, W, a, r, s, a, w] > " [0] E " E > " [1] u " u > " [2] r " r > " [3] o " o > " [4] p " p > " [5] e " e > " [6] / " / > " [7] W " W > " [8] a " a > " [9] r " r > " [10] s " s > " [11] a " a > " [12] w " w > " lastRule null " null > " offsets (id=95) " [3600000, 5040000, 7200000, 3600000, 10800000] > " [0] 3600000 " 3600000 > " [1] 5040000 " 5040000 > " [2] 7200000 " 7200000 > " [3] 3600000 " 3600000 > " [4] 10800000 " 10800000 > " rawOffset 3600000 " 3600000 > " rawOffsetDiff 0 " 0 > " simpleTimeZoneParams (id=97) " [2, -1, 1, 3600000, 2, 9, -1, 1, 3600000, 2] > " [0] 2 " 2 > " [1] -1 " -1 > " [2] 1 " 1 > " [3] 3600000 " 3600000 > " [4] 2 " 2 > " [5] 9 " 9 > " [6] -1 " -1 > " [7] 1 " 1 > " [8] 3600000 " 3600000 > " [9] 2 " 2 > " transitions (id=98) " [-9048018124799999, -7032964055040000, -6937421414399950, -6883260825600000, -6813514137599950, -6759014400000000, -6684696575999950, -6630196838399998, -6555539865599948, -6501040127999998, -6151068057600000, -3816382463999950, -3511325491200000, -3459303014399950, -3392416972800000, -3328008191999950, -3262906368000000, -3189664972799950, -3123855360000000, -3065801932799950, -3003487027200000, -2929523097599950, -2875023360000000, -2805660057599950, -2746205798400000, -2679319756799950, -2617388236800000, -1626498662399950, -1584385228800000, -1519976447999950, -1455567667200000, -1368863539199950, -1324272844800000, -1259864063999950, -1195455283200000, -1111228415999950, -1066637721600000, -982410854399950, -937820160000000, -853593292799950, -809002598400000, -722298470399950, -680185036800000, 937466265600050, 999397785600000, 1066283827200050, 1130692608000000, 1195101388800050, 1259510169600000, 1326396211200050, 1388327731200000, 1452736512000050, 1517145292800000, 1581554073600050, 1645962854400000, 1710371635200050, 1774780416000000, 1839189196800050, 1906075238400000, 1970484019200050, 2034892800000000, 2099301580800050, 2163710361600000, 2228119142400050, 2292527923200000, 2356951449600050, 2421360230400000, 2485769011200050, 2550177792000000, 2614586572800050, 2681472614400000, 2745881395200050, 2810290176000000, 2874698956800050, 2939107737600000, 3003516518400050, 3067925299200000, 3132334080000050, 3196742860800000, 3261151641600050, 3325560422400000, 3392446464000050, 3466764288000000, 3521264025600050, 3595581849600000, 3650081587200050, 3724399411200000, 3778899148800050, 3855694233600000, 3907716710400050, 3984511795200000, 4036534272000050, 4113329356800000, 4167829094400050, 4242146918400000, 4296646656000050, 4370964480000000, 4425464217600050, 4502259302400000, 4554281779200050, 4631076864000000, 4683099340800050, 4759894425600000, 4811916902400050, 4888711987200000, 4943211724800050, 5017529548800000, 5072029286400050, 5146347110400000, 5200846848000050, 5277641932800000, 5329664409600050, 5406459494400000, 5458481971200050, 5535277056000000, 5589776793600050, 5664094617600000, 5718594355200050, 5792912179200000, 5847411916800050, 5921729740800000, 5976229478400050, 6053024563200000, 6105047040000050, 6181842124800000, 6233864601600050, 6310659686400000, 6365159424000050, 6439477248000000, 6493976985600050, 6568294809600000, 6622794547200050, 6699589632000000, 6751612108800050, 6828407193600000, 6880429670400050, 6957224755200000, 7011724492800050, 7086042316800000, 7140542054400050, 7214859878400000, 7269359616000050, 7343677440000000, 7398177177600050, 7474972262400000, 7526994739200050, 7603789824000000, 7655812300800050, 7732607385600000, 7787107123200050, 7861424947200000, 7915924684800050, 7990242508800000, 8044742246400050, 8121537331200000, 8173559808000050, 8250354892800000, 8302377369600050, 8379172454400000, 8431194931200050, 8507990016000000, 8562489753600050, 8636807577600000, 8691307315200050, 8765625139200000] > " [0...99] " > " [0] -9048018124799999 " -9048018124800000 > " [1] -7032964055040000 " -7032964055040000 > " [2] -6937421414399950 " -6937421414399950 > " [3] -6883260825600000 " -6883260825600000 > " [4] -6813514137599950 " -6813514137599950 > " [5] -6759014400000000 " -6759014400000000 > " [6] -6684696575999950 " -6684696575999950 > " [7] -6630196838399998 " -6630196838400000 > " [8] -6555539865599948 " -6555539865599950 > " [9] -6501040127999998 " -6501040128000000 > " [10] -6151068057600000 " -6151068057600000 > " [11] -3816382463999950 " -3816382463999950 > " [12] -3511325491200000 " -3511325491200000 > " [13] -3459303014399950 " -3459303014399950 > " [14] -3392416972800000 " -3392416972800000 > " [15] -3328008191999950 " -3328008191999950 > " [16] -3262906368000000 " -3262906368000000 > " [17] -3189664972799950 " -3189664972799950 > " [18] -3123855360000000 " -3123855360000000 > " [19] -3065801932799950 " -3065801932799950 > " [20] -3003487027200000 " -3003487027200000 > " [21] -2929523097599950 " -2929523097599950 > " [22] -2875023360000000 " -2875023360000000 > " [23] -2805660057599950 " -2805660057599950 > " [24] -2746205798400000 " -2746205798400000 > " [25] -2679319756799950 " -2679319756799950 > " [26] -2617388236800000 " -2617388236800000 > " [27] -1626498662399950 " -1626498662399950 > " [28] -1584385228800000 " -1584385228800000 > " [29] -1519976447999950 " -1519976447999950 > " [30] -1455567667200000 " -1455567667200000 > " [31] -1368863539199950 " -1368863539199950 > " [32] -1324272844800000 " -1324272844800000 > " [33] -1259864063999950 " -1259864063999950 > " [34] -1195455283200000 " -1195455283200000 > " [35] -1111228415999950 " -1111228415999950 > " [36] -1066637721600000 " -1066637721600000 > " [37] -982410854399950 " -982410854399950 > " [38] -937820160000000 " -937820160000000 > " [39] -853593292799950 " -853593292799950 > " [40] -809002598400000 " -809002598400000 > " [41] -722298470399950 " -722298470399950 > " [42] -680185036800000 " -680185036800000 > " [43] 937466265600050 " 937466265600050 > " [44] 999397785600000 " 999397785600000 > " [45] 1066283827200050 " 1066283827200050 > " [46] 1130692608000000 " 1130692608000000 > " [47] 1195101388800050 " 1195101388800050 > " [48] 1259510169600000 " 1259510169600000 > " [49] 1326396211200050 " 1326396211200050 > " [50] 1388327731200000 " 1388327731200000 > " [51] 1452736512000050 " 1452736512000050 > " [52] 1517145292800000 " 1517145292800000 > " [53] 1581554073600050 " 1581554073600050 > " [54] 1645962854400000 " 1645962854400000 > " [55] 1710371635200050 " 1710371635200050 > " [56] 1774780416000000 " 1774780416000000 > " [57] 1839189196800050 " 1839189196800050 > " [58] 1906075238400000 " 1906075238400000 > " [59] 1970484019200050 " 1970484019200050 > " [60] 2034892800000000 " 2034892800000000 > " [61] 2099301580800050 " 2099301580800050 > " [62] 2163710361600000 " 2163710361600000 > " [63] 2228119142400050 " 2228119142400050 > " [64] 2292527923200000 " 2292527923200000 > " [65] 2356951449600050 " 2356951449600050 > " [66] 2421360230400000 " 2421360230400000 > " [67] 2485769011200050 " 2485769011200050 > " [68] 2550177792000000 " 2550177792000000 > " [69] 2614586572800050 " 2614586572800050 > " [70] 2681472614400000 " 2681472614400000 > " [71] 2745881395200050 " 2745881395200050 > " [72] 2810290176000000 " 2810290176000000 > " [73] 2874698956800050 " 2874698956800050 > " [74] 2939107737600000 " 2939107737600000 > " [75] 3003516518400050 " 3003516518400050 > " [76] 3067925299200000 " 3067925299200000 > " [77] 3132334080000050 " 3132334080000050 > " [78] 3196742860800000 " 3196742860800000 > " [79] 3261151641600050 " 3261151641600050 > " [80] 3325560422400000 " 3325560422400000 > " [81] 3392446464000050 " 3392446464000050 > " [82] 3466764288000000 " 3466764288000000 > " [83] 3521264025600050 " 3521264025600050 > " [84] 3595581849600000 " 3595581849600000 > " [85] 3650081587200050 " 3650081587200050 > " [86] 3724399411200000 " 3724399411200000 > " [87] 3778899148800050 " 3778899148800050 > " [88] 3855694233600000 " 3855694233600000 > " [89] 3907716710400050 " 3907716710400050 > " [90] 3984511795200000 " 3984511795200000 > " [91] 4036534272000050 " 4036534272000050 > " [92] 4113329356800000 " 4113329356800000 > " [93] 4167829094400050 " 4167829094400050 > " [94] 4242146918400000 " 4242146918400000 > " [95] 4296646656000050 " 4296646656000050 > " [96] 4370964480000000 " 4370964480000000 > " [97] 4425464217600050 " 4425464217600050 > " [98] 4502259302400000 " 4502259302400000 > " [99] 4554281779200050 " 4554281779200050 > " [100...164] " > " [100] 4631076864000000 " 4631076864000000 > " [101] 4683099340800050 " 4683099340800050 > " [102] 4759894425600000 " 4759894425600000 > " [103] 4811916902400050 " 4811916902400050 > " [104] 4888711987200000 " 4888711987200000 > " [105] 4943211724800050 " 4943211724800050 > " [106] 5017529548800000 " 5017529548800000 > " [107] 5072029286400050 " 5072029286400050 > " [108] 5146347110400000 " 5146347110400000 > " [109] 5200846848000050 " 5200846848000050 > " [110] 5277641932800000 " 5277641932800000 > " [111] 5329664409600050 " 5329664409600050 > " [112] 5406459494400000 " 5406459494400000 > " [113] 5458481971200050 " 5458481971200050 > " [114] 5535277056000000 " 5535277056000000 > " [115] 5589776793600050 " 5589776793600050 > " [116] 5664094617600000 " 5664094617600000 > " [117] 5718594355200050 " 5718594355200050 > " [118] 5792912179200000 " 5792912179200000 > " [119] 5847411916800050 " 5847411916800050 > " [120] 5921729740800000 " 5921729740800000 > " [121] 5976229478400050 " 5976229478400050 > " [122] 6053024563200000 " 6053024563200000 > " [123] 6105047040000050 " 6105047040000050 > " [124] 6181842124800000 " 6181842124800000 > " [125] 6233864601600050 " 6233864601600050 > " [126] 6310659686400000 " 6310659686400000 > " [127] 6365159424000050 " 6365159424000050 > " [128] 6439477248000000 " 6439477248000000 > " [129] 6493976985600050 " 6493976985600050 > " [130] 6568294809600000 " 6568294809600000 > " [131] 6622794547200050 " 6622794547200050 > " [132] 6699589632000000 " 6699589632000000 > " [133] 6751612108800050 " 6751612108800050 > " [134] 6828407193600000 " 6828407193600000 > " [135] 6880429670400050 " 6880429670400050 > " [136] 6957224755200000 " 6957224755200000 > " [137] 7011724492800050 " 7011724492800050 > " [138] 7086042316800000 " 7086042316800000 > " [139] 7140542054400050 " 7140542054400050 > " [140] 7214859878400000 " 7214859878400000 > " [141] 7269359616000050 " 7269359616000050 > " [142] 7343677440000000 " 7343677440000000 > " [143] 7398177177600050 " 7398177177600050 > " [144] 7474972262400000 " 7474972262400000 > " [145] 7526994739200050 " 7526994739200050 > " [146] 7603789824000000 " 7603789824000000 > " [147] 7655812300800050 " 7655812300800050 > " [148] 7732607385600000 " 7732607385600000 > " [149] 7787107123200050 " 7787107123200050 > " [150] 7861424947200000 " 7861424947200000 > " [151] 7915924684800050 " 7915924684800050 > " [152] 7990242508800000 " 7990242508800000 > " [153] 8044742246400050 " 8044742246400050 > " [154] 8121537331200000 " 8121537331200000 > " [155] 8173559808000050 " 8173559808000050 > " [156] 8250354892800000 " 8250354892800000 > " [157] 8302377369600050 " 8302377369600050 > " [158] 8379172454400000 " 8379172454400000 > " [159] 8431194931200050 " 8431194931200050 > " [160] 8507990016000000 " 8507990016000000 > " [161] 8562489753600050 " 8562489753600050 > " [162] 8636807577600000 " 8636807577600000 > " [163] 8691307315200050 " 8691307315200050 > " [164] 8765625139200000 " 8765625139200000 > " willGMTOffsetChange false " FALSE > " zoneOffset 3600000 " 3600000 > " fastTime 1416438000000 " 1416438000000 > {code} > {code} > NO CACHE OBJECT > "dataOd Date (id=123) " 2014-11-20 > " cdate Gregorian$Date (id=129) " 2014-11-20T00:00:00.000+0100 > " cachedFixedDateJan1 735234 " 735234 > " cachedFixedDateNextJan1 735599 " 735599 > " cachedYear 2014 " 2014 > " daylightSaving 0 " 0 > " dayOfMonth 20 " 20 > " dayOfWeek 5 " 5 > " era null " null > " forceStandardTime false " FALSE > " fraction 0 " 0 > " hours 0 " 0 > " leapYear false " FALSE > " locale null " null > " millis 0 " 0 > " minutes 0 " 0 > " month 11 " 11 > " normalized true " TRUE > " seconds 0 " 0 > " year 2014 " 2014 > " zoneinfo ZoneInfo (id=86) " sun.util.calendar.ZoneInfo[id="Europe/Warsaw",offset=3600000,dstSavings=3600000,useDaylight=true,transitions=165,lastRule=java.util.SimpleTimeZone[id=Europe/Warsaw,offset=3600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=1,startTime=3600000,startTimeMode=2,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=1,endTime=3600000,endTimeMode=2]] > " checksum -1578751392 " -1578751392 > " dirty false " FALSE > " dstSavings 3600000 " 3600000 > " ID ""Europe/Warsaw"" (id=92) " Europe/Warsaw > " count 13 " 13 > " hash 826225934 " 826225934 > " offset 0 " 0 > " value (id=100) " [E, u, r, o, p, e, /, W, a, r, s, a, w] > " [0] E " E > " [1] u " u > " [2] r " r > " [3] o " o > " [4] p " p > " [5] e " e > " [6] / " / > " [7] W " W > " [8] a " a > " [9] r " r > " [10] s " s > " [11] a " a > " [12] w " w > " lastRule null " null > " offsets (id=95) " [3600000, 5040000, 7200000, 3600000, 10800000] > " [0] 3600000 " 3600000 > " [1] 5040000 " 5040000 > " [2] 7200000 " 7200000 > " [3] 3600000 " 3600000 > " [4] 10800000 " 10800000 > " rawOffset 3600000 " 3600000 > " rawOffsetDiff 0 " 0 > " simpleTimeZoneParams (id=97) " [2, -1, 1, 3600000, 2, 9, -1, 1, 3600000, 2] > " [0] 2 " 2 > " [1] -1 " -1 > " [2] 1 " 1 > " [3] 3600000 " 3600000 > " [4] 2 " 2 > " [5] 9 " 9 > " [6] -1 " -1 > " [7] 1 " 1 > " [8] 3600000 " 3600000 > " [9] 2 " 2 > " transitions (id=98) " [-9048018124799999, -7032964055040000, -6937421414399950, -6883260825600000, -6813514137599950, -6759014400000000, -6684696575999950, -6630196838399998, -6555539865599948, -6501040127999998, -6151068057600000, -3816382463999950, -3511325491200000, -3459303014399950, -3392416972800000, -3328008191999950, -3262906368000000, -3189664972799950, -3123855360000000, -3065801932799950, -3003487027200000, -2929523097599950, -2875023360000000, -2805660057599950, -2746205798400000, -2679319756799950, -2617388236800000, -1626498662399950, -1584385228800000, -1519976447999950, -1455567667200000, -1368863539199950, -1324272844800000, -1259864063999950, -1195455283200000, -1111228415999950, -1066637721600000, -982410854399950, -937820160000000, -853593292799950, -809002598400000, -722298470399950, -680185036800000, 937466265600050, 999397785600000, 1066283827200050, 1130692608000000, 1195101388800050, 1259510169600000, 1326396211200050, 1388327731200000, 1452736512000050, 1517145292800000, 1581554073600050, 1645962854400000, 1710371635200050, 1774780416000000, 1839189196800050, 1906075238400000, 1970484019200050, 2034892800000000, 2099301580800050, 2163710361600000, 2228119142400050, 2292527923200000, 2356951449600050, 2421360230400000, 2485769011200050, 2550177792000000, 2614586572800050, 2681472614400000, 2745881395200050, 2810290176000000, 2874698956800050, 2939107737600000, 3003516518400050, 3067925299200000, 3132334080000050, 3196742860800000, 3261151641600050, 3325560422400000, 3392446464000050, 3466764288000000, 3521264025600050, 3595581849600000, 3650081587200050, 3724399411200000, 3778899148800050, 3855694233600000, 3907716710400050, 3984511795200000, 4036534272000050, 4113329356800000, 4167829094400050, 4242146918400000, 4296646656000050, 4370964480000000, 4425464217600050, 4502259302400000, 4554281779200050, 4631076864000000, 4683099340800050, 4759894425600000, 4811916902400050, 4888711987200000, 4943211724800050, 5017529548800000, 5072029286400050, 5146347110400000, 5200846848000050, 5277641932800000, 5329664409600050, 5406459494400000, 5458481971200050, 5535277056000000, 5589776793600050, 5664094617600000, 5718594355200050, 5792912179200000, 5847411916800050, 5921729740800000, 5976229478400050, 6053024563200000, 6105047040000050, 6181842124800000, 6233864601600050, 6310659686400000, 6365159424000050, 6439477248000000, 6493976985600050, 6568294809600000, 6622794547200050, 6699589632000000, 6751612108800050, 6828407193600000, 6880429670400050, 6957224755200000, 7011724492800050, 7086042316800000, 7140542054400050, 7214859878400000, 7269359616000050, 7343677440000000, 7398177177600050, 7474972262400000, 7526994739200050, 7603789824000000, 7655812300800050, 7732607385600000, 7787107123200050, 7861424947200000, 7915924684800050, 7990242508800000, 8044742246400050, 8121537331200000, 8173559808000050, 8250354892800000, 8302377369600050, 8379172454400000, 8431194931200050, 8507990016000000, 8562489753600050, 8636807577600000, 8691307315200050, 8765625139200000] > " [0...99] " > " [0] -9048018124799999 " -9048018124800000 > " [1] -7032964055040000 " -7032964055040000 > " [2] -6937421414399950 " -6937421414399950 > " [3] -6883260825600000 " -6883260825600000 > " [4] -6813514137599950 " -6813514137599950 > " [5] -6759014400000000 " -6759014400000000 > " [6] -6684696575999950 " -6684696575999950 > " [7] -6630196838399998 " -6630196838400000 > " [8] -6555539865599948 " -6555539865599950 > " [9] -6501040127999998 " -6501040128000000 > " [10] -6151068057600000 " -6151068057600000 > " [11] -3816382463999950 " -3816382463999950 > " [12] -3511325491200000 " -3511325491200000 > " [13] -3459303014399950 " -3459303014399950 > " [14] -3392416972800000 " -3392416972800000 > " [15] -3328008191999950 " -3328008191999950 > " [16] -3262906368000000 " -3262906368000000 > " [17] -3189664972799950 " -3189664972799950 > " [18] -3123855360000000 " -3123855360000000 > " [19] -3065801932799950 " -3065801932799950 > " [20] -3003487027200000 " -3003487027200000 > " [21] -2929523097599950 " -2929523097599950 > " [22] -2875023360000000 " -2875023360000000 > " [23] -2805660057599950 " -2805660057599950 > " [24] -2746205798400000 " -2746205798400000 > " [25] -2679319756799950 " -2679319756799950 > " [26] -2617388236800000 " -2617388236800000 > " [27] -1626498662399950 " -1626498662399950 > " [28] -1584385228800000 " -1584385228800000 > " [29] -1519976447999950 " -1519976447999950 > " [30] -1455567667200000 " -1455567667200000 > " [31] -1368863539199950 " -1368863539199950 > " [32] -1324272844800000 " -1324272844800000 > " [33] -1259864063999950 " -1259864063999950 > " [34] -1195455283200000 " -1195455283200000 > " [35] -1111228415999950 " -1111228415999950 > " [36] -1066637721600000 " -1066637721600000 > " [37] -982410854399950 " -982410854399950 > " [38] -937820160000000 " -937820160000000 > " [39] -853593292799950 " -853593292799950 > " [40] -809002598400000 " -809002598400000 > " [41] -722298470399950 " -722298470399950 > " [42] -680185036800000 " -680185036800000 > " [43] 937466265600050 " 937466265600050 > " [44] 999397785600000 " 999397785600000 > " [45] 1066283827200050 " 1066283827200050 > " [46] 1130692608000000 " 1130692608000000 > " [47] 1195101388800050 " 1195101388800050 > " [48] 1259510169600000 " 1259510169600000 > " [49] 1326396211200050 " 1326396211200050 > " [50] 1388327731200000 " 1388327731200000 > " [51] 1452736512000050 " 1452736512000050 > " [52] 1517145292800000 " 1517145292800000 > " [53] 1581554073600050 " 1581554073600050 > " [54] 1645962854400000 " 1645962854400000 > " [55] 1710371635200050 " 1710371635200050 > " [56] 1774780416000000 " 1774780416000000 > " [57] 1839189196800050 " 1839189196800050 > " [58] 1906075238400000 " 1906075238400000 > " [59] 1970484019200050 " 1970484019200050 > " [60] 2034892800000000 " 2034892800000000 > " [61] 2099301580800050 " 2099301580800050 > " [62] 2163710361600000 " 2163710361600000 > " [63] 2228119142400050 " 2228119142400050 > " [64] 2292527923200000 " 2292527923200000 > " [65] 2356951449600050 " 2356951449600050 > " [66] 2421360230400000 " 2421360230400000 > " [67] 2485769011200050 " 2485769011200050 > " [68] 2550177792000000 " 2550177792000000 > " [69] 2614586572800050 " 2614586572800050 > " [70] 2681472614400000 " 2681472614400000 > " [71] 2745881395200050 " 2745881395200050 > " [72] 2810290176000000 " 2810290176000000 > " [73] 2874698956800050 " 2874698956800050 > " [74] 2939107737600000 " 2939107737600000 > " [75] 3003516518400050 " 3003516518400050 > " [76] 3067925299200000 " 3067925299200000 > " [77] 3132334080000050 " 3132334080000050 > " [78] 3196742860800000 " 3196742860800000 > " [79] 3261151641600050 " 3261151641600050 > " [80] 3325560422400000 " 3325560422400000 > " [81] 3392446464000050 " 3392446464000050 > " [82] 3466764288000000 " 3466764288000000 > " [83] 3521264025600050 " 3521264025600050 > " [84] 3595581849600000 " 3595581849600000 > " [85] 3650081587200050 " 3650081587200050 > " [86] 3724399411200000 " 3724399411200000 > " [87] 3778899148800050 " 3778899148800050 > " [88] 3855694233600000 " 3855694233600000 > " [89] 3907716710400050 " 3907716710400050 > " [90] 3984511795200000 " 3984511795200000 > " [91] 4036534272000050 " 4036534272000050 > " [92] 4113329356800000 " 4113329356800000 > " [93] 4167829094400050 " 4167829094400050 > " [94] 4242146918400000 " 4242146918400000 > " [95] 4296646656000050 " 4296646656000050 > " [96] 4370964480000000 " 4370964480000000 > " [97] 4425464217600050 " 4425464217600050 > " [98] 4502259302400000 " 4502259302400000 > " [99] 4554281779200050 " 4554281779200050 > " [100...164] " > " [100] 4631076864000000 " 4631076864000000 > " [101] 4683099340800050 " 4683099340800050 > " [102] 4759894425600000 " 4759894425600000 > " [103] 4811916902400050 " 4811916902400050 > " [104] 4888711987200000 " 4888711987200000 > " [105] 4943211724800050 " 4943211724800050 > " [106] 5017529548800000 " 5017529548800000 > " [107] 5072029286400050 " 5072029286400050 > " [108] 5146347110400000 " 5146347110400000 > " [109] 5200846848000050 " 5200846848000050 > " [110] 5277641932800000 " 5277641932800000 > " [111] 5329664409600050 " 5329664409600050 > " [112] 5406459494400000 " 5406459494400000 > " [113] 5458481971200050 " 5458481971200050 > " [114] 5535277056000000 " 5535277056000000 > " [115] 5589776793600050 " 5589776793600050 > " [116] 5664094617600000 " 5664094617600000 > " [117] 5718594355200050 " 5718594355200050 > " [118] 5792912179200000 " 5792912179200000 > " [119] 5847411916800050 " 5847411916800050 > " [120] 5921729740800000 " 5921729740800000 > " [121] 5976229478400050 " 5976229478400050 > " [122] 6053024563200000 " 6053024563200000 > " [123] 6105047040000050 " 6105047040000050 > " [124] 6181842124800000 " 6181842124800000 > " [125] 6233864601600050 " 6233864601600050 > " [126] 6310659686400000 " 6310659686400000 > " [127] 6365159424000050 " 6365159424000050 > " [128] 6439477248000000 " 6439477248000000 > " [129] 6493976985600050 " 6493976985600050 > " [130] 6568294809600000 " 6568294809600000 > " [131] 6622794547200050 " 6622794547200050 > " [132] 6699589632000000 " 6699589632000000 > " [133] 6751612108800050 " 6751612108800050 > " [134] 6828407193600000 " 6828407193600000 > " [135] 6880429670400050 " 6880429670400050 > " [136] 6957224755200000 " 6957224755200000 > " [137] 7011724492800050 " 7011724492800050 > " [138] 7086042316800000 " 7086042316800000 > " [139] 7140542054400050 " 7140542054400050 > " [140] 7214859878400000 " 7214859878400000 > " [141] 7269359616000050 " 7269359616000050 > " [142] 7343677440000000 " 7343677440000000 > " [143] 7398177177600050 " 7398177177600050 > " [144] 7474972262400000 " 7474972262400000 > " [145] 7526994739200050 " 7526994739200050 > " [146] 7603789824000000 " 7603789824000000 > " [147] 7655812300800050 " 7655812300800050 > " [148] 7732607385600000 " 7732607385600000 > " [149] 7787107123200050 " 7787107123200050 > " [150] 7861424947200000 " 7861424947200000 > " [151] 7915924684800050 " 7915924684800050 > " [152] 7990242508800000 " 7990242508800000 > " [153] 8044742246400050 " 8044742246400050 > " [154] 8121537331200000 " 8121537331200000 > " [155] 8173559808000050 " 8173559808000050 > " [156] 8250354892800000 " 8250354892800000 > " [157] 8302377369600050 " 8302377369600050 > " [158] 8379172454400000 " 8379172454400000 > " [159] 8431194931200050 " 8431194931200050 > " [160] 8507990016000000 " 8507990016000000 > " [161] 8562489753600050 " 8562489753600050 > " [162] 8636807577600000 " 8636807577600000 > " [163] 8691307315200050 " 8691307315200050 > " [164] 8765625139200000 " 8765625139200000 > " willGMTOffsetChange false " FALSE > " zoneOffset 3600000 " 3600000 > " fastTime 1416438000000 " 1416438000000 > {code} > After comparing them in diff viewer - the difference is only in first two lines: > |"dataOd Date (id=72) "| Thu Nov 20 00:00:00 CET 2014 |"dataOd Date (id=123) "| 2014-11-20| > |" cdate Gregorian$Date (id=82) "| 2014-11-20T00:00:00.000+0100 |" cdate Gregorian$Date (id=129) "| 2014-11-20T00:00:00.000+0100| > in first line - toString and id, in second line - only id > Why date in object read from cache (after creating in same session) has different toString than read from no cache - objects in debugger looks same, so I really don't know what is the problem -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 05:14:39 2014 From: issues at jboss.org (Diego Fiozzi (JIRA)) Date: Mon, 17 Nov 2014 05:14:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBWEB-307) FormAuthenticator doesn't restore SavedRequest body after login In-Reply-To: References: Message-ID: Diego Fiozzi created JBWEB-307: ---------------------------------- Summary: FormAuthenticator doesn't restore SavedRequest body after login Key: JBWEB-307 URL: https://issues.jboss.org/browse/JBWEB-307 Project: JBoss Web Issue Type: Bug Components: Tomcat Affects Versions: JBossWeb-7.0.13.GA Environment: Winfows 7, Jboss as 7.1.1 final (Jbossweb 7.0.13 final), JDK6 Reporter: Diego Fiozzi Assignee: Remy Maucherat Priority: Blocker i'm porting my application from tomcat to jboss as 7.1.1 final. it include smartgwt, spring. i use jaas login:
tion="j_security_check"> to my custom login class which implements javax.security.auth.spi.LoginModule after login goes well, the execution flow goes to my spring controller: @RequestMapping(value="/all", method=RequestMethod.POST) @ResponseBody public String all(@RequestBody String json,HttpSession session, HttpServletRequest servletrequest) throws Exception { but the "json" parameter is null. The cause seems to be in this method public boolean authenticate(Request request, HttpServletResponse response, LoginConfig config) in org.apache.catalina.authenticator.FormAuthenticator class, in the last part, after the .authenticate: principal = realm.authenticate(username, password); if (principal == null) { forwardToErrorPage(request, response, config); return (false); } if (log.isDebugEnabled()) log.debug("Authentication of '" + username + "' was successful"); if (session == null) session = request.getSessionInternal(false); if (session == null) { if (containerLog.isDebugEnabled()) containerLog.debug ("User took so long to log on the session expired"); response.sendError(HttpServletResponse.SC_REQUEST_TIMEOUT, sm.getString("authenticator.sessionExpired")); return (false); } // Save the authenticated Principal in our session session.setNote(Constants.FORM_PRINCIPAL_NOTE, principal); // Save the username and password as well session.setNote(Constants.SESS_USERNAME_NOTE, username); session.setNote(Constants.SESS_PASSWORD_NOTE, password); // Redirect the user to the original request URI (which will cause // the original request to be restored) requestURI = savedRequestURL(session); if (log.isDebugEnabled()) log.debug("Redirecting to original '" + requestURI + "'"); if (requestURI == null) response.sendError(HttpServletResponse.SC_BAD_REQUEST, sm.getString("authenticator.formlogin")); else response.sendRedirect(response.encodeRedirectURL(requestURI)); return (false); in debug i've found my json: in session there is a "note" field which contains a SavedRequest object: https://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/authenticator/SavedRequest.html it is a container of the request before login, and it has my json in his body field. its uri is restored (line #32) not the entire request. i suppose it should make a call of session.setNote(Constants.FORM_REQUEST_NOTE, saved); in every cases, like it does for SESS_USERNAME_NOTE, SESS_PASSWORD_NOTE and FORM_PRINCIPAL_NOTE -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 06:32:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 17 Nov 2014 06:32:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-256) Remove comment from schema that says Kerberos is only possible for HTTP In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-256: --------------------------------------- Summary: Remove comment from schema that says Kerberos is only possible for HTTP Key: WFCORE-256 URL: https://issues.jboss.org/browse/WFCORE-256 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha13 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 06:55:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 17 Nov 2014 06:55:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-257) Need access constraints for server-name and sasl-protocol for management. In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-257: --------------------------------------- Summary: Need access constraints for server-name and sasl-protocol for management. Key: WFCORE-257 URL: https://issues.jboss.org/browse/WFCORE-257 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 1.0.0.Alpha13 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 07:18:39 2014 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Mon, 17 Nov 2014 07:18:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-859) Authentication failure due to a login module misconfiguration is not reported if principal is null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen updated SECURITY-859: ------------------------------------ Fix Version/s: PicketBox_4_9_0.Beta2 (was: PicketBox_4_9_0.Beta1) > Authentication failure due to a login module misconfiguration is not reported if principal is null > -------------------------------------------------------------------------------------------------- > > Key: SECURITY-859 > URL: https://issues.jboss.org/browse/SECURITY-859 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Affects Versions: PicketBox_4_0_21.Beta2, PicketBox_4_0_19.SP5 > Reporter: Ivo Studensky > Assignee: Peter Skopek > Fix For: PicketBox_4_1_0.Beta1, PicketBox_4_9_0.Beta2 > > > Any misconfiguration of a login module leading to authentication failure used to be reported at trace level for anonymous user (principal == null) until SECURITY-660. Right now it is reported at debug level, but only if principal != null. > I am going to propose a fix to report the cause of such a failure at debug level despite the principal value. So that customers can see for example "javax.security.auth.login.LoginException: unable to find LoginModule class: ..." in their logs instead of "PBOX000016: Access denied" only. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 07:19:39 2014 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Mon, 17 Nov 2014 07:19:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-859) Authentication failure due to a login module misconfiguration is not reported if principal is null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen updated SECURITY-859: ------------------------------------ Fix Version/s: PicketBox_4_9_0.Beta3 (was: PicketBox_4_9_0.Beta2) > Authentication failure due to a login module misconfiguration is not reported if principal is null > -------------------------------------------------------------------------------------------------- > > Key: SECURITY-859 > URL: https://issues.jboss.org/browse/SECURITY-859 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Affects Versions: PicketBox_4_0_21.Beta2, PicketBox_4_0_19.SP5 > Reporter: Ivo Studensky > Assignee: Peter Skopek > Fix For: PicketBox_4_1_0.Beta1, PicketBox_4_9_0.Beta3 > > > Any misconfiguration of a login module leading to authentication failure used to be reported at trace level for anonymous user (principal == null) until SECURITY-660. Right now it is reported at debug level, but only if principal != null. > I am going to propose a fix to report the cause of such a failure at debug level despite the principal value. So that customers can see for example "javax.security.auth.login.LoginException: unable to find LoginModule class: ..." in their logs instead of "PBOX000016: Access denied" only. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 07:21:39 2014 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Mon, 17 Nov 2014 07:21:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-859) Authentication failure due to a login module misconfiguration is not reported if principal is null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen resolved SECURITY-859. ------------------------------------- Resolution: Done The fix was merged a month ago > Authentication failure due to a login module misconfiguration is not reported if principal is null > -------------------------------------------------------------------------------------------------- > > Key: SECURITY-859 > URL: https://issues.jboss.org/browse/SECURITY-859 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Affects Versions: PicketBox_4_0_21.Beta2, PicketBox_4_0_19.SP5 > Reporter: Ivo Studensky > Assignee: Peter Skopek > Fix For: PicketBox_4_1_0.Beta1, PicketBox_4_9_0.Beta3 > > > Any misconfiguration of a login module leading to authentication failure used to be reported at trace level for anonymous user (principal == null) until SECURITY-660. Right now it is reported at debug level, but only if principal != null. > I am going to propose a fix to report the cause of such a failure at debug level despite the principal value. So that customers can see for example "javax.security.auth.login.LoginException: unable to find LoginModule class: ..." in their logs instead of "PBOX000016: Access denied" only. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 07:25:39 2014 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Mon, 17 Nov 2014 07:25:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-867) AppPolicy.java and AuthenticationInfo.java should use Security Manager instead of Access Controller In-Reply-To: References: Message-ID: Stefan Guilhen created SECURITY-867: --------------------------------------- Summary: AppPolicy.java and AuthenticationInfo.java should use Security Manager instead of Access Controller Key: SECURITY-867 URL: https://issues.jboss.org/browse/SECURITY-867 Project: PicketBox Issue Type: Enhancement Components: JBossSX Affects Versions: PicketBox_4_0_21_Beta3, PicketBox_4_9_0.Beta1 Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: PicketBox_4_9_0.Beta3 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 07:35:39 2014 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Mon, 17 Nov 2014 07:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-867) AppPolicy.java and AuthenticationInfo.java should use Security Manager instead of Access Controller In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen resolved SECURITY-867. ------------------------------------- Resolution: Done > AppPolicy.java and AuthenticationInfo.java should use Security Manager instead of Access Controller > --------------------------------------------------------------------------------------------------- > > Key: SECURITY-867 > URL: https://issues.jboss.org/browse/SECURITY-867 > Project: PicketBox > Issue Type: Enhancement > Components: JBossSX > Affects Versions: PicketBox_4_9_0.Beta1, PicketBox_4_0_21_Beta3 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_0.Beta3 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 08:23:41 2014 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Mon, 17 Nov 2014 08:23:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020446#comment-13020446 ] Scott Marlow commented on WFLY-2387: ------------------------------------ Is the best test case still at [https://issues.jboss.org/browse/WFLY-2387?focusedCommentId=12826416&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12826416]? How does that fail? If there is an updated failure (other than "Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 5bedfb57.") could you please attach it. The current attachment reflects an already fixed "Singleton not set for " error. > CDI injection in entity listeners failing > ----------------------------------------- > > Key: WFLY-2387 > URL: https://issues.jboss.org/browse/WFLY-2387 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Class Loading, JPA / Hibernate > Affects Versions: 8.0.0.Beta1 > Reporter: Emond Papegaaij > Assignee: Scott Marlow > Fix For: 9.0.0.Beta1 > > Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml > > > When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception: > {code} > 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25] > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3] > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] > Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader at 4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75) > at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128) > at org.jboss.weld.Container.instance(Container.java:65) > at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) > at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60) > at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) > at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.(BeanManagerListenerFactory.java:82) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.(BeanManagerListenerFactory.java:71) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57) > at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168) > at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71) > at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150) > at org.hibernate.internal.SessionFactoryImpl.(SessionFactoryImpl.java:310) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847) > at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846) > at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) > ... 8 more > {code} > I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 08:59:39 2014 From: issues at jboss.org (Wolf-Dieter Fink (JIRA)) Date: Mon, 17 Nov 2014 08:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4090) Ability to add an alias for ejb invocations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wolf-Dieter Fink updated WFLY-4090: ----------------------------------- Component/s: EJB > Ability to add an alias for ejb invocations > ------------------------------------------- > > Key: WFLY-4090 > URL: https://issues.jboss.org/browse/WFLY-4090 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Affects Versions: 8.1.0.Final > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > By default a EJB will install standards a JNDI name like > //! > Additional JNDI entries, i.e. for internal use or remote naming , could be installed by @Resource annotation or jboss-ejb3.xml descriptor. > But it is not possiblet to use the ejb-client approach with an "ejb:" lookup to retrieve a remote-reference to this EJB. > For applicaion backward compatibility it should be possible to install aliases like > ejb/MyBean > myapp/mymodule/MyBean/myView > with different values than the unique installed one and useable by the "ejb:" context. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 09:01:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Mon, 17 Nov 2014 09:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4090) Ability to add an alias for ejb invocations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd reassigned WFLY-4090: --------------------------------- Assignee: David Lloyd (was: Jason Greene) > Ability to add an alias for ejb invocations > ------------------------------------------- > > Key: WFLY-4090 > URL: https://issues.jboss.org/browse/WFLY-4090 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Affects Versions: 8.1.0.Final > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > > By default a EJB will install standards a JNDI name like > //! > Additional JNDI entries, i.e. for internal use or remote naming , could be installed by @Resource annotation or jboss-ejb3.xml descriptor. > But it is not possiblet to use the ejb-client approach with an "ejb:" lookup to retrieve a remote-reference to this EJB. > For applicaion backward compatibility it should be possible to install aliases like > ejb/MyBean > myapp/mymodule/MyBean/myView > with different values than the unique installed one and useable by the "ejb:" context. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 09:33:39 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Mon, 17 Nov 2014 09:33:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1235) rar-info: ResourceAdapterAssociation In-Reply-To: References: Message-ID: Jesper Pedersen created JBJCA-1235: -------------------------------------- Summary: rar-info: ResourceAdapterAssociation Key: JBJCA-1235 URL: https://issues.jboss.org/browse/JBJCA-1235 Project: IronJacamar Issue Type: Task Components: AS Reporter: Jesper Pedersen Assignee: Jeff Zhang Fix For: 1.2.1.Final The rar-info tool should report the status of javax.resource.spi.ResourceAdapterAssociation for ManagedConnectionFactory and AdminObject {noformat} Class: com.acme.eis.MCFImpl Validating: No Association: Yes Sharable: Unknown ... Class: com.acme.eis.AOImpl Association: Yes Interface: javax.jms.Topic ... {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 10:05:40 2014 From: issues at jboss.org (Marc Dzaebel (JIRA)) Date: Mon, 17 Nov 2014 10:05:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Duplicate method call inside patterns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020474#comment-13020474 ] Marc Dzaebel commented on DROOLS-651: ------------------------------------- The documentation uses the term _binding variable_ 8 times, so bindings seems to be a variables too (but of course special ones). I understand that these bindings are not yet cached because of constraint idempotence. However, in my view the implication should be, that especially a non changing result +can+ be cached! Rather than a _good practice_, the documentation says: "Property accessors +must+ not change the state of the object in a way that may effect the rules. Remember that the rule engine effectively caches the results of its matching in between invocations to make it faster.". So if kind of functional immutability is required and used inside the engine, I would indeed think about caching method calls (with variables) in constraints, as this saves potentially massive processor time and would be much more intuitive. I don't understand the sentence "If you can't or desire not to guarantee this property, Drools won't enforce it caching the first value returned.". Is it possible, to enforce Drools to cache variable bindings? Let me say that I'm still intrigued about the huge, powerful Drools framework and that we get this as Open Source. Feel free to change the issue-type to a feature request, as the behavior is not strictly incorrect but optimizable. > Duplicate method call inside patterns > ------------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mark Proctor > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 10:24:39 2014 From: issues at jboss.org (Gunnar Morling (JIRA)) Date: Mon, 17 Nov 2014 10:24:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-84) Provide mechanism for preparing string representations of logged objects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGTOOL-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020480#comment-13020480 ] Gunnar Morling commented on LOGTOOL-84: --------------------------------------- Yes, it seems related. In fact, {{@FormatWith}} appears to be what I'm after, just learned about it. I'll give that a try. Though what I had in mind here would go a bit farther, as it basically would specify default {{@FormatWith}} 's based on the parameter type, without the need to specify the formatter type for each single parameter. Btw. the pull request for LOGTOOL-55 is merged, still the issue itself is open. Shouldn't it be marked as resolved? > Provide mechanism for preparing string representations of logged objects > ------------------------------------------------------------------------ > > Key: LOGTOOL-84 > URL: https://issues.jboss.org/browse/LOGTOOL-84 > Project: Log Tool > Issue Type: Feature Request > Reporter: Gunnar Morling > Assignee: David Lloyd > > There are cases where a fine-grained control of the string representation of logged objects in log messages would be useful. > When logging {{Class}} objects for instance, we would like to see the fully-qualified name of the given class in the log message. Currently we get _(class|interface) com.acme.Foo_, though, as per the implementation of {{j.l.Class#toString()}}, which prepends the type of the given class object. > As workaround, we currently define the log method to accept a String parameter and pass {{myClass.getName()}} to it. Having a strongly typed log method which takes the "real" object as parameter seems preferable, though. > A possible solution could be a mechanism which allows to register to-string converters for given types with a logger: > {code} > //Provided by JBoss Logging API > public interface StringConverter { > String createString(T object); > } > //A project-specific implementation > public class ClassStringConverter implements StringConverter> { > public String createString(Class object) { > return object.getName(); > } > } > //Project-specific logger, references 1..n converters > @MessageLogger(projectCode = "HV", converters=ClassStringConverter.class) > public interface Log extends BasicLogger { > //implementation uses converter to create string representation of given class > @LogMessage(level = INFO) > @Message(id = 1, value = "Illegal class %s") > void illegalClass(Class clazz); > } > {code} > Would such a feature make sense to you? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 10:26:40 2014 From: issues at jboss.org (Marc Dzaebel (JIRA)) Date: Mon, 17 Nov 2014 10:26:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Duplicate method call inside patterns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020474#comment-13020474 ] Marc Dzaebel edited comment on DROOLS-651 at 11/17/14 10:26 AM: ---------------------------------------------------------------- The documentation uses the term _binding variable_ 8 times, so bindings seems to be a variables too (but of course special ones). I understand that these bindings are not yet cached because of constraint idempotence. However, in my view the implication should be, that especially a non changing result +can+ be cached! Rather than a _good practice_, the documentation says: {quote} "Property accessors +must+ not change the state of the object in a way that may effect the rules. Remember that the rule engine effectively +caches+ the results of its matching in between invocations to make it faster." {quote} So if kind of functional immutability is required and used inside the engine, I would indeed think about caching method calls (with variables) in constraints, as this saves potentially massive processor time and would be much more intuitive. I don't understand your sentence {quote} "If you can't or desire not to guarantee this property, Drools won't enforce it caching the first value returned." {quote} Is it possible, to enforce Drools to cache variable bindings? Drools shouldn't cache values, that change. Let me say that I'm still intrigued about the huge, powerful Drools framework and that we get this as Open Source including this helpful support. Feel free to change the issue-type to a feature request, as the behavior is not strictly incorrect but optimizable. was (Author: mdzaebel): The documentation uses the term _binding variable_ 8 times, so bindings seems to be a variables too (but of course special ones). I understand that these bindings are not yet cached because of constraint idempotence. However, in my view the implication should be, that especially a non changing result +can+ be cached! Rather than a _good practice_, the documentation says: "Property accessors +must+ not change the state of the object in a way that may effect the rules. Remember that the rule engine effectively caches the results of its matching in between invocations to make it faster.". So if kind of functional immutability is required and used inside the engine, I would indeed think about caching method calls (with variables) in constraints, as this saves potentially massive processor time and would be much more intuitive. I don't understand the sentence "If you can't or desire not to guarantee this property, Drools won't enforce it caching the first value returned.". Is it possible, to enforce Drools to cache variable bindings? Let me say that I'm still intrigued about the huge, powerful Drools framework and that we get this as Open Source. Feel free to change the issue-type to a feature request, as the behavior is not strictly incorrect but optimizable. > Duplicate method call inside patterns > ------------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mark Proctor > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 11:11:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 17 Nov 2014 11:11:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-257) Need access constraints for server-name and sasl-protocol for management. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-257: ------------------------------------ Priority: Minor (was: Critical) > Need access constraints for server-name and sasl-protocol for management. > ------------------------------------------------------------------------- > > Key: WFCORE-257 > URL: https://issues.jboss.org/browse/WFCORE-257 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 11:12:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 17 Nov 2014 11:12:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-257) Remove TODO comment saying we need access constraints for server-name and sasl-protocol for management. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-257: ------------------------------------ Summary: Remove TODO comment saying we need access constraints for server-name and sasl-protocol for management. (was: Need access constraints for server-name and sasl-protocol for management.) > Remove TODO comment saying we need access constraints for server-name and sasl-protocol for management. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-257 > URL: https://issues.jboss.org/browse/WFCORE-257 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 11:15:40 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 17 Nov 2014 11:15:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-257) Remove TODO comment saying we need access constraints for server-name and sasl-protocol for management. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-257: ------------------------------------ Description: The management interfaces are already flagged as MANAGEMENT_INTERFACES so access is already restricted to all attributes, we don't need an additional access constraint. > Remove TODO comment saying we need access constraints for server-name and sasl-protocol for management. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-257 > URL: https://issues.jboss.org/browse/WFCORE-257 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 1.0.0.Alpha13 > > > The management interfaces are already flagged as MANAGEMENT_INTERFACES so access is already restricted to all attributes, we don't need an additional access constraint. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 11:16:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Mon, 17 Nov 2014 11:16:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020511#comment-13020511 ] Emmanuel Hugonnet commented on WFCORE-242: ------------------------------------------ The content is removed in a ResultHandler thus the effective removal is done after adding the deployment resource. > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 11:33:39 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 17 Nov 2014 11:33:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-258) Enable security manager via JBoss Modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins moved WFLY-3932 to WFCORE-258: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-258 (was: WFLY-3932) Component/s: Security (was: Security Manager) > Enable security manager via JBoss Modules > ----------------------------------------- > > Key: WFCORE-258 > URL: https://issues.jboss.org/browse/WFCORE-258 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: James Perkins > Assignee: James Perkins > > In WildFly Core the security manager can be enabled via the {{-secmgr}} argument or setting the {{SECMGR=true}} environment variable. In order for this change to work correctly the {{WildFlySecurityManager.install()}} needs to be disabled. > Also -all- standalone, process-controller and host-controller modules that declare a dependency on {{org.wildfly.security.manager}} need to export the services. > The security manager test suite configuration needs to be updated to use the {{-secmgr}} argument rather than using {{-Dsecurity.manager}} to transform the profile (though the same system property should probably be reused to add the argument, like we had originally done). > Test suite configuration needs to be updated to *always* enable the security manager subsystem, even if the security manager is disabled. This will cause the permissions to still be associated with deployments (though they will not be used unless -secmgr was passed to the startup script). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 11:53:39 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 17 Nov 2014 11:53:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4091) Disable WildFlySecurtyManager.install() in security manager subsystem In-Reply-To: References: Message-ID: James Perkins created WFLY-4091: ----------------------------------- Summary: Disable WildFlySecurtyManager.install() in security manager subsystem Key: WFLY-4091 URL: https://issues.jboss.org/browse/WFLY-4091 Project: WildFly Issue Type: Feature Request Components: Security Manager Reporter: James Perkins Assignee: James Perkins The security-manager subsystem invokes {{WildFlySecurityManager.install()}} which needs to be disabled. The security manager will be enabled via jboss-modules by passing {{-secmgr}} via the command line at startup or by setting the {{SECMGR=true}} environment variable. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 12:05:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Mon, 17 Nov 2014 12:05:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Duplicate method call inside patterns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco updated DROOLS-651: ------------------------------- Issue Type: Enhancement (was: Bug) > Duplicate method call inside patterns > ------------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mark Proctor > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 12:14:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Mon, 17 Nov 2014 12:14:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet updated WFCORE-242: ------------------------------------- Priority: Minor (was: Major) > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 12:15:40 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Mon, 17 Nov 2014 12:15:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020529#comment-13020529 ] Emmanuel Hugonnet commented on WFCORE-242: ------------------------------------------ This has nothing to do with the CLI nor the ordering of operations on the server side, so I'm decreasing the priority. This behaviour is incorrect but there is a simple workaround using --force in the deploy command to avoid it. > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 12:25:39 2014 From: issues at jboss.org (John O'Hara (JIRA)) Date: Mon, 17 Nov 2014 12:25:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1236) Race condition in SemaphoreConcurrentLinkedQueueManagedConnectionPool In-Reply-To: References: Message-ID: John O'Hara created JBJCA-1236: ---------------------------------- Summary: Race condition in SemaphoreConcurrentLinkedQueueManagedConnectionPool Key: JBJCA-1236 URL: https://issues.jboss.org/browse/JBJCA-1236 Project: IronJacamar Issue Type: Bug Components: Core Affects Versions: 1.2.0.Final Reporter: John O'Hara Assignee: Jesper Pedersen A race condition in the ConnectionListenerWrapper and incorrect logic when returning the ConnectionListener object to the ConcurrentLinkedQueue means that stale field values are sometimes seen for ConnectionListenerWrapper.hasPermit(). Under heavy contention, a stale value in hasPermit() means permits.release() is not called and the semaphores available reduce over time. The mcp effectively shrinks over time. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 12:43:39 2014 From: issues at jboss.org (John O'Hara (JIRA)) Date: Mon, 17 Nov 2014 12:43:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1236) Race condition in SemaphoreConcurrentLinkedQueueManagedConnectionPool In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020536#comment-13020536 ] John O'Hara commented on JBJCA-1236: ------------------------------------ PR for 1.2: https://github.com/ironjacamar/ironjacamar/pull/259 > Race condition in SemaphoreConcurrentLinkedQueueManagedConnectionPool > --------------------------------------------------------------------- > > Key: JBJCA-1236 > URL: https://issues.jboss.org/browse/JBJCA-1236 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.2.0.Final > Reporter: John O'Hara > Assignee: Jesper Pedersen > > A race condition in the ConnectionListenerWrapper and incorrect logic when returning the ConnectionListener object to the ConcurrentLinkedQueue means that stale field values are sometimes seen for ConnectionListenerWrapper.hasPermit(). > Under heavy contention, a stale value in hasPermit() means permits.release() is not called and the semaphores available reduce over time. > The mcp effectively shrinks over time. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 12:49:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 17 Nov 2014 12:49:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-259) Improve realm readiness handling In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-259: --------------------------------------- Summary: Improve realm readiness handling Key: WFCORE-259 URL: https://issues.jboss.org/browse/WFCORE-259 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha13 Currently we display an error message informing users that they need to add a new user if any of the authentication mechanisms within a realm report that they are not ready to handle requests. The reason for this was so that if properties backed authentication we available along with local authentication then the local authentication would not prevent the prompt from being displayed. However there could be additional mechanisms suitable for use with HTTP so we need a small modification to stop taking into account the local authentication mechanism but allow requests in if any of the other HTTP compatible mechanisms are ready to handle requests. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 13:20:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Mon, 17 Nov 2014 13:20:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4091) Disable WildFlySecurtyManager.install() in security manager subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020551#comment-13020551 ] David Lloyd commented on WFLY-4091: ----------------------------------- This was already fixed via https://github.com/wildfly/wildfly/pull/6956. > Disable WildFlySecurtyManager.install() in security manager subsystem > --------------------------------------------------------------------- > > Key: WFLY-4091 > URL: https://issues.jboss.org/browse/WFLY-4091 > Project: WildFly > Issue Type: Feature Request > Components: Security Manager > Reporter: James Perkins > Assignee: James Perkins > > The security-manager subsystem invokes {{WildFlySecurityManager.install()}} which needs to be disabled. The security manager will be enabled via jboss-modules by passing {{-secmgr}} via the command line at startup or by setting the {{SECMGR=true}} environment variable. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 13:30:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 13:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2551) AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020553#comment-13020553 ] RH Bugzilla Integration commented on WFLY-2551: ----------------------------------------------- Kabir Khan changed the Status of [bug 1150821|https://bugzilla.redhat.com/show_bug.cgi?id=1150821] from POST to MODIFIED > AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation > -------------------------------------------------------------------------------- > > Key: WFLY-2551 > URL: https://issues.jboss.org/browse/WFLY-2551 > Project: WildFly > Issue Type: Bug > Components: JCA, JMX > Reporter: Will Tatam > Assignee: Brian Stansberry > Fix For: 9.0.0.Alpha1 > > > If you just create a basic datasource under AS 7.2 the you can view the current statistics about the pool under > jboss.as:subsystem=datasources,data-source=mySQL,statistics=pool > However, if you add the following then sometimes the statistics=pool and statistics=jdbc entries disspaear > select 1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 13:30:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 13:30:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020554#comment-13020554 ] RH Bugzilla Integration commented on WFLY-4054: ----------------------------------------------- Kabir Khan changed the Status of [bug 1156032|https://bugzilla.redhat.com/show_bug.cgi?id=1156032] from POST to MODIFIED > Unexpected attribute can be added to elements in Transactions Subsystem > ----------------------------------------------------------------------- > > Key: WFLY-4054 > URL: https://issues.jboss.org/browse/WFLY-4054 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. > When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 14:06:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Mon, 17 Nov 2014 14:06:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3865) java:jboss/exported is not available in @PreDestroy methods during shutdown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020558#comment-13020558 ] David Lloyd commented on WFLY-3865: ----------------------------------- TBH I don't think this is a bug. If the server is shutting down, there's no reason for the EJB container to retain a handle to some remote JNDI name. If you want a dependency on the name then you have to use {{@Resource}} or a resource-ref of some sort. > java:jboss/exported is not available in @PreDestroy methods during shutdown > --------------------------------------------------------------------------- > > Key: WFLY-3865 > URL: https://issues.jboss.org/browse/WFLY-3865 > Project: WildFly > Issue Type: Feature Request > Components: Naming > Affects Versions: 8.1.0.Final > Reporter: Kyle Lape > Assignee: Eduardo Martins > > With the following code in a class named e.g. {{JNDIBinderBean.java}} > {code:java} > private static final String name = "java:jboss/exported/JNDIBinderBean"; > private static final String value = "JNDIBinderBean instantiated at " + new Date(); > @PostConstruct > public void start() { > new InitialContext().rebind(name, value); > } > @PreDestroy > public void stop() { > new InitialContext().unbind(name); > } > {code} > When Wildfly shuts down, I get an error saying that the MSC service isn't available: > {noformat} > javax.naming.NamingException: JBAS011836: Could not resolve service > service jboss.naming.context.java.jboss.exported.JNDIBinderBean > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 14:31:39 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Mon, 17 Nov 2014 14:31:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4091) Disable WildFlySecurtyManager.install() in security manager subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFLY-4091. ------------------------------- Resolution: Duplicate Issue Already fixed in WFLY-3932 > Disable WildFlySecurtyManager.install() in security manager subsystem > --------------------------------------------------------------------- > > Key: WFLY-4091 > URL: https://issues.jboss.org/browse/WFLY-4091 > Project: WildFly > Issue Type: Feature Request > Components: Security Manager > Reporter: James Perkins > Assignee: James Perkins > > The security-manager subsystem invokes {{WildFlySecurityManager.install()}} which needs to be disabled. The security manager will be enabled via jboss-modules by passing {{-secmgr}} via the command line at startup or by setting the {{SECMGR=true}} environment variable. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 14:34:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 17 Nov 2014 14:34:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-260) Kerberos authentication not working on the IBM JVM In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-260: --------------------------------------- Summary: Kerberos authentication not working on the IBM JVM Key: WFCORE-260 URL: https://issues.jboss.org/browse/WFCORE-260 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha13 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 14:34:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 14:34:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-260) Kerberos authentication not working on the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-260: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1161589 > Kerberos authentication not working on the IBM JVM > -------------------------------------------------- > > Key: WFCORE-260 > URL: https://issues.jboss.org/browse/WFCORE-260 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 14:34:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 14:34:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-260) Kerberos authentication not working on the IBM JVM In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020568#comment-13020568 ] RH Bugzilla Integration commented on WFCORE-260: ------------------------------------------------ Darran Lofthouse changed the Status of [bug 1161589|https://bugzilla.redhat.com/show_bug.cgi?id=1161589] from NEW to ASSIGNED > Kerberos authentication not working on the IBM JVM > -------------------------------------------------- > > Key: WFCORE-260 > URL: https://issues.jboss.org/browse/WFCORE-260 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 14:38:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 14:38:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-259) Improve realm readiness handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-259: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1161668 > Improve realm readiness handling > -------------------------------- > > Key: WFCORE-259 > URL: https://issues.jboss.org/browse/WFCORE-259 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > > Currently we display an error message informing users that they need to add a new user if any of the authentication mechanisms within a realm report that they are not ready to handle requests. > The reason for this was so that if properties backed authentication we available along with local authentication then the local authentication would not prevent the prompt from being displayed. > However there could be additional mechanisms suitable for use with HTTP so we need a small modification to stop taking into account the local authentication mechanism but allow requests in if any of the other HTTP compatible mechanisms are ready to handle requests. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 15:52:39 2014 From: issues at jboss.org (Marcus Carlson (JIRA)) Date: Mon, 17 Nov 2014 15:52:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3987) Regression regarding WS Client when using header authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020581#comment-13020581 ] Marcus Carlson commented on WFLY-3987: -------------------------------------- Hm. Not sure everything is well anyway. I've been trying for the last couple of days to get HelpDesk_Query_Service method working but with no luck. Both HelpDesk_QueryList_Service and HelpDesk_GetWorkInfoList seems to be working just fine with the workaround. The only difference I can find is that HelpDesk_Query_Service is translated into a void method with output parameters and the other some kind of list object. Testing this outside of Wildfly with just a simple main method and manually creating the HPDIncidentInterfaceWSService field to a new instance and run it's working every time. Not sure what implementations are used then - maybe standard Java / Sun (?) libraries. So, something is not working that well although I'm workaround this by not using the methods at all at the moment... Let me know if there's anything you need to know or something I should test. > Regression regarding WS Client when using header authentication > --------------------------------------------------------------- > > Key: WFLY-3987 > URL: https://issues.jboss.org/browse/WFLY-3987 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final, 9.0.0.Alpha1 > Environment: Linux (Ubuntu 14.04), OpenJDK 1.7.0_65, Wildfly 8.0/8.1/9.0A > Reporter: Marcus Carlson > Assignee: Alessio Soldano > > I'm trying to integrate a Web Service client based on BMC Remedy product where Web service authentication is handled in Soap Header and not basic authentication. See AuthenticationInfo element on https://github.com/macmorning/itsm_mobileview/blob/master/SoapUI%20Projects/HPD-IncidentInterface-WS---v8-soapui-project.xml for an example of how the WSDL file looks like. > I've enabled Xadditionalheaders so I get the AuthenticationInfo as the last argument, like this: > {noformat} > port.helpDeskQueryListService(qualification, startRecord, maxLimit, authInfo); > {noformat} > Problem is that this was working fine in WildFly 8.0 generating the following SOAP Request: > {noformat} > ID: 1 > Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_IncidentInterface_WS > Encoding: UTF-8 > Http-Method: POST > Content-Type: text/xml > Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]} > Payload: SECRETUSERSECRETPASSWORD'Status' = "Closed"01000 > {noformat} > With 8.1 it's generating a completly different payload with the Header element in Body and body completly missing (!): > {noformat} > ID: 2 > Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_IncidentInterface_WS > Encoding: UTF-8 > Http-Method: POST > Content-Type: text/xml > Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]} > Payload: SECRETUSERSECRETPASSWORD > {noformat} > I've also tried 9.0.0.Alpha1 with same result. What could be wrong? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 16:39:39 2014 From: issues at jboss.org (Marc Dzaebel (JIRA)) Date: Mon, 17 Nov 2014 16:39:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Duplicate method call inside patterns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020591#comment-13020591 ] Marc Dzaebel commented on DROOLS-651: ------------------------------------- In the meantime, documentation could be adapted by something like: ... Remember that the rule engine effectively caches the results of its matching in between invocations to make it faster. *However, currently binding variables are not cached.* > Duplicate method call inside patterns > ------------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mark Proctor > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 18:10:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 18:10:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4079) Wildfly does not consider methods with no method-intf element when resolving transaction attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020608#comment-13020608 ] RH Bugzilla Integration commented on WFLY-4079: ----------------------------------------------- Paul Gier changed the Status of [bug 1164060|https://bugzilla.redhat.com/show_bug.cgi?id=1164060] from MODIFIED to ON_QA > Wildfly does not consider methods with no method-intf element when resolving transaction attributes > --------------------------------------------------------------------------------------------------- > > Key: WFLY-4079 > URL: https://issues.jboss.org/browse/WFLY-4079 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > If there is a method without a method-intf the ejb-jar.xml it will not be considered when determining the transaction attribute. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 18:10:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 18:10:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4074) pop3 mail session throws a NoSuchProviderException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020609#comment-13020609 ] RH Bugzilla Integration commented on WFLY-4074: ----------------------------------------------- Paul Gier changed the Status of [bug 1163150|https://bugzilla.redhat.com/show_bug.cgi?id=1163150] from MODIFIED to ON_QA > pop3 mail session throws a NoSuchProviderException > -------------------------------------------------- > > Key: WFLY-4074 > URL: https://issues.jboss.org/browse/WFLY-4074 > Project: WildFly > Issue Type: Bug > Components: Mail > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > When configuring a pop3 server in standalone.xml as, the following exception is thrown when reading the mailbox: > {noformat} > Caused by: javax.mail.NoSuchProviderException: Invalid protocol: null > at javax.mail.Session.getProvider(Session.java:440) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > at javax.mail.Session.getStore(Session.java:539) [mail-1.4.5-redhat-1.jar:1.4.5-redhat-1] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 18:10:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 18:10:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2551) AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020610#comment-13020610 ] RH Bugzilla Integration commented on WFLY-2551: ----------------------------------------------- Paul Gier changed the Status of [bug 1150821|https://bugzilla.redhat.com/show_bug.cgi?id=1150821] from MODIFIED to ON_QA > AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation > -------------------------------------------------------------------------------- > > Key: WFLY-2551 > URL: https://issues.jboss.org/browse/WFLY-2551 > Project: WildFly > Issue Type: Bug > Components: JCA, JMX > Reporter: Will Tatam > Assignee: Brian Stansberry > Fix For: 9.0.0.Alpha1 > > > If you just create a basic datasource under AS 7.2 the you can view the current statistics about the pool under > jboss.as:subsystem=datasources,data-source=mySQL,statistics=pool > However, if you add the following then sometimes the statistics=pool and statistics=jdbc entries disspaear > select 1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 18:10:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 18:10:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020613#comment-13020613 ] RH Bugzilla Integration commented on WFLY-4054: ----------------------------------------------- Paul Gier changed the Status of [bug 1156032|https://bugzilla.redhat.com/show_bug.cgi?id=1156032] from MODIFIED to ON_QA > Unexpected attribute can be added to elements in Transactions Subsystem > ----------------------------------------------------------------------- > > Key: WFLY-4054 > URL: https://issues.jboss.org/browse/WFLY-4054 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. > When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 18:11:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 18:11:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1149) Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020615#comment-13020615 ] RH Bugzilla Integration commented on WFLY-1149: ----------------------------------------------- Paul Gier changed the Status of [bug 923836|https://bugzilla.redhat.com/show_bug.cgi?id=923836] from MODIFIED to ON_QA > Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open. > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1149 > URL: https://issues.jboss.org/browse/WFLY-1149 > Project: WildFly > Issue Type: Bug > Components: Naming, Test Suite > Environment: IBM JDK 6 (build 20110203_074623) > IBM JDK 7 (build 20120809_118929) > Reporter: Ivo Studensky > Assignee: Jason Greene > Attachments: endpoint_is_not_open_2012-11-26.xml, failed_with_status_cancelled_2012-11-26.xml, test_output_with_trace_logging_in_EndpointCache.xml > > > RemoteNamingTestCase intermittently fails when running on IBM JDK. According to logs the remoting channel had been closed before the endpoint tried to connect to it. Unfortunately, when I was trying to debug this issue the tests always nicely passed. > test.log snippet: > {noformat} > 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" read-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" read-1', selector sun.nio.ch.EPollSelectorImpl at 345642e1 > 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" write-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" write-1', selector sun.nio.ch.EPollSelectorImpl at 1dc68cf2 > 13:16:31,121 DEBUG [org.jboss.naming.remote.client.InitialContextFactory] (main) jboss.naming.client.connect.options. has the following options {org.xnio.Options.SASL_POLICY_NOPLAINTEXT=>false} > 13:16:31,191 ERROR [org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1] (Remoting "config-based-naming-client-endpoint" task-1) Channel end notification received, closing channel Channel ID d1f17196 (outbound) of Remoting connection fd3dcedc to /127.0.0.1:4447 > 13:16:31,204 DEBUG [org.jboss.naming.remote.client.HaRemoteNamingStore] (main) Failed to connect to server remote://127.0.0.1:4447: org.jboss.remoting3.NotOpenException: Endpoint is not open > at org.jboss.remoting3.EndpointImpl.resourceUntick(EndpointImpl.java:182) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:261) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333) > at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105) > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:179) > at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:117) > at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83) > at javax.naming.InitialContext.lookup(InitialContext.java:422) > at org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase.testRemoteLookup(RemoteNamingTestCase.java:74) > {noformat} > server.log snippet: > {noformat} > 13:16:31,025 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "test.jar" > 13:16:31,163 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-3) Channel Opened - Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 > 13:16:31,176 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-4) Chosen version 0x01 > 13:16:31,189 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" read-1) Channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 closed. > 13:16:31,193 INFO [org.jboss.as.naming] (Remoting "thinkpax" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to null > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 17 22:30:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 17 Nov 2014 22:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020633#comment-13020633 ] RH Bugzilla Integration commented on WFLY-4089: ----------------------------------------------- James Livingston changed the Status of [bug 1164600|https://bugzilla.redhat.com/show_bug.cgi?id=1164600] from NEW to POST > ServletContainerInitializerDeploymentProcessor does not handle comments > ----------------------------------------------------------------------- > > Key: WFLY-4089 > URL: https://issues.jboss.org/browse/WFLY-4089 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: James Livingston > Assignee: Stuart Douglas > > ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. > The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. > Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 01:48:39 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Tue, 18 Nov 2014 01:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-235) CtClassType.getEnclosingBehavior() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shigeru Chiba resolved JASSIST-235. ----------------------------------- Fix Version/s: 3.19.0-GA Resolution: Done I've added getEnclosingBehavior() and made getEnclosingMethod() deprecated because it may potentially cause a bug. > CtClassType.getEnclosingBehavior() > ---------------------------------- > > Key: JASSIST-235 > URL: https://issues.jboss.org/browse/JASSIST-235 > Project: Javassist > Issue Type: Enhancement > Affects Versions: 3.19.0-GA > Reporter: Maximilian Scherr > Assignee: Shigeru Chiba > Priority: Minor > Labels: CtBehavior, class, enclosing, inner, method > Fix For: 3.19.0-GA > > Original Estimate: 2 days > Remaining Estimate: 2 days > > The method {{getEnclosingMethod()}} in {{CtClassType}} (or {{CtClass}}) only works with non-constructor methods ({{CtMethod}}). > However, the JVM's {{Enclosing Method Attribute}} is not restricted to non-constructor methods ({{CtMethod}}). > Method-local inner classes can be declared within constructors. > I suggest the addition of a {{getEnclosingBehavior()}} method as follows: > {code:title=getEnclosingBehavior|borderStyle=solid} > public CtBehavior getEnclosingBehavior() throws NotFoundException { > ClassFile cf = getClassFile2(); > EnclosingMethodAttribute ema > = (EnclosingMethodAttribute)cf.getAttribute( > EnclosingMethodAttribute.tag); > if (ema != null) { > CtClass enc = classPool.get(ema.className()); > String name = ema.methodName(); > switch (name) { > case MethodInfo.nameInit: > return enc.getConstructor(ema.methodDescriptor()); > case MethodInfo.nameClinit: > return enc.getClassInitializer(); > default: > return enc.getMethod(name, ema.methodDescriptor()); > } > } > return null; > } > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 01:49:39 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Tue, 18 Nov 2014 01:49:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-235) CtClassType.getEnclosingBehavior() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shigeru Chiba closed JASSIST-235. --------------------------------- > CtClassType.getEnclosingBehavior() > ---------------------------------- > > Key: JASSIST-235 > URL: https://issues.jboss.org/browse/JASSIST-235 > Project: Javassist > Issue Type: Enhancement > Affects Versions: 3.19.0-GA > Reporter: Maximilian Scherr > Assignee: Shigeru Chiba > Priority: Minor > Labels: CtBehavior, class, enclosing, inner, method > Fix For: 3.19.0-GA > > Original Estimate: 2 days > Remaining Estimate: 2 days > > The method {{getEnclosingMethod()}} in {{CtClassType}} (or {{CtClass}}) only works with non-constructor methods ({{CtMethod}}). > However, the JVM's {{Enclosing Method Attribute}} is not restricted to non-constructor methods ({{CtMethod}}). > Method-local inner classes can be declared within constructors. > I suggest the addition of a {{getEnclosingBehavior()}} method as follows: > {code:title=getEnclosingBehavior|borderStyle=solid} > public CtBehavior getEnclosingBehavior() throws NotFoundException { > ClassFile cf = getClassFile2(); > EnclosingMethodAttribute ema > = (EnclosingMethodAttribute)cf.getAttribute( > EnclosingMethodAttribute.tag); > if (ema != null) { > CtClass enc = classPool.get(ema.className()); > String name = ema.methodName(); > switch (name) { > case MethodInfo.nameInit: > return enc.getConstructor(ema.methodDescriptor()); > case MethodInfo.nameClinit: > return enc.getClassInitializer(); > default: > return enc.getMethod(name, ema.methodDescriptor()); > } > } > return null; > } > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 02:39:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 02:39:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3847) AS7BindingRegistry does not respect the SPI contract In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020653#comment-13020653 ] RH Bugzilla Integration commented on WFLY-3847: ----------------------------------------------- Ond?ej Kalman changed the Status of [bug 1124178|https://bugzilla.redhat.com/show_bug.cgi?id=1124178] from ON_QA to ASSIGNED > AS7BindingRegistry does not respect the SPI contract > ---------------------------------------------------- > > Key: WFLY-3847 > URL: https://issues.jboss.org/browse/WFLY-3847 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > Fix For: 9.0.0.Alpha1 > > > The implementation of AS7BindingRegistry#lookup always return null. > This method is called by HornetQ when JNDI entries for its resources > are updated using its own management API. > We advise against using it in WildFly (and use WildFly own management API) but we must still respect the SPI contract for this method. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 02:50:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 02:50:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-161) JMX monitoring is extremely memory inefficient In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020656#comment-13020656 ] RH Bugzilla Integration commented on WFCORE-161: ------------------------------------------------ Panagiotis Sotiropoulos changed the Status of [bug 1154868|https://bugzilla.redhat.com/show_bug.cgi?id=1154868] from ASSIGNED to POST > JMX monitoring is extremely memory inefficient > ---------------------------------------------- > > Key: WFCORE-161 > URL: https://issues.jboss.org/browse/WFCORE-161 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Koen Janssens > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha11 > > > When reading any JMX attribute(s), I have noticed a noticeable impact on the performance of our system. After attaching a profiler, I see that getting a single attribute of a JMX bean (either using remoting or using jconsole) is generating thousands of objects, that have to cleaned up by the GC. For instance, 6000 instances of the ModelNode class are created. > A clone is made of the complete management model before executing any JMX operation. This happens in the OperationContextImpl.readResourceFromRoot class. > More background on associated forum thread -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 04:25:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 04:25:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-129) Overlay does not work for subunits in exploded deployments. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020679#comment-13020679 ] RH Bugzilla Integration commented on WFCORE-129: ------------------------------------------------ baranowb changed the Status of [bug 1147352|https://bugzilla.redhat.com/show_bug.cgi?id=1147352] from ASSIGNED to POST > Overlay does not work for subunits in exploded deployments. > ----------------------------------------------------------- > > Key: WFCORE-129 > URL: https://issues.jboss.org/browse/WFCORE-129 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha8 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Alpha13 > > > If deployment is exploded and has subdeployments overlay wont work on files contained in said subdeployments. > Reproducers: https://github.com/baranowb/wildfly/tree/WFCORE-83-TESTS -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 04:54:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 04:54:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1247) graceful shutdown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020689#comment-13020689 ] RH Bugzilla Integration commented on WFLY-1247: ----------------------------------------------- baranowb changed the Status of [bug 971679|https://bugzilla.redhat.com/show_bug.cgi?id=971679] from ASSIGNED to CLOSED > graceful shutdown > ----------------- > > Key: WFLY-1247 > URL: https://issues.jboss.org/browse/WFLY-1247 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Stuart Douglas > > We need to define a clear contract between these networking services and the services that use them in order to be able to perform a graceful shutdown of remote connectors. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 05:00:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 05:00:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020690#comment-13020690 ] RH Bugzilla Integration commented on WFLY-4054: ----------------------------------------------- Hayk Hovsepyan changed the Status of [bug 1156032|https://bugzilla.redhat.com/show_bug.cgi?id=1156032] from ON_QA to MODIFIED > Unexpected attribute can be added to elements in Transactions Subsystem > ----------------------------------------------------------------------- > > Key: WFLY-4054 > URL: https://issues.jboss.org/browse/WFLY-4054 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. > When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 05:36:39 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 18 Nov 2014 05:36:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4092) GC Overhead issue when building WildFly Full Feature Pack In-Reply-To: References: Message-ID: Michael Musgrove created WFLY-4092: -------------------------------------- Summary: GC Overhead issue when building WildFly Full Feature Pack Key: WFLY-4092 URL: https://issues.jboss.org/browse/WFLY-4092 Project: WildFly Issue Type: Bug Components: Build System Affects Versions: 9.0.0.Alpha1 Reporter: Michael Musgrove Assignee: Paul Gier When we build wildfly master on some of our CI cluster machines (and Toms laptop) we are getting GC overhead limit exceeded errors building the Full Feature Pack. This started happening about 6 weeks or so ago. We have fixed it in our config by passing "-XX:+UseConcMarkSweepGC to maven via MAVEN_OPTS but ideally it needs setting in the wildfly build script. The maven error is: [ERROR] GC overhead limit exceeded -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/OutOfMemoryError -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 06:04:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Tue, 18 Nov 2014 06:04:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020529#comment-13020529 ] Emmanuel Hugonnet edited comment on WFCORE-242 at 11/18/14 6:04 AM: -------------------------------------------------------------------- This has nothing to do with the CLI nor the ordering of operations on the server side, so I'm decreasing the priority. This behaviour is incorrect but there is a simple workaround using --force in the deploy command to avoid it. With the fix, you'll need to start the deployment with a */server-group=main-server-group/deployment=wildfly-ejb-in-war.war:deploy* was (Author: ehugonnet): This has nothing to do with the CLI nor the ordering of operations on the server side, so I'm decreasing the priority. This behaviour is incorrect but there is a simple workaround using --force in the deploy command to avoid it. > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 06:05:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Tue, 18 Nov 2014 06:05:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020529#comment-13020529 ] Emmanuel Hugonnet edited comment on WFCORE-242 at 11/18/14 6:05 AM: -------------------------------------------------------------------- This has nothing to do with the CLI nor the ordering of operations on the server side, so I'm decreasing the priority. This behaviour is incorrect but there is a simple workaround using --force in the deploy command to avoid it. With the fix, you'll need to start the deployment : {code} batch undeploy example.war --server-groups=main-server-group deploy /PATH/TO/example.war --name=example.war --server-groups=main-server-group run-batch /server-group=main-server-group/deployment=example.war:deploy {code} was (Author: ehugonnet): This has nothing to do with the CLI nor the ordering of operations on the server side, so I'm decreasing the priority. This behaviour is incorrect but there is a simple workaround using --force in the deploy command to avoid it. With the fix, you'll need to start the deployment with a */server-group=main-server-group/deployment=wildfly-ejb-in-war.war:deploy* > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 06:07:40 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Tue, 18 Nov 2014 06:07:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020529#comment-13020529 ] Emmanuel Hugonnet edited comment on WFCORE-242 at 11/18/14 6:07 AM: -------------------------------------------------------------------- This has nothing to do with the CLI nor the ordering of operations on the server side, so I'm decreasing the priority. This behaviour is incorrect but there is a simple workaround using --force in the deploy command to avoid it. With the fix, you'll need to start the deployment after the batch : {code} batch undeploy example.war --server-groups=main-server-group deploy /PATH/TO/example.war --name=example.war --server-groups=main-server-group run-batch /server-group=main-server-group/deployment=example.war:deploy {code} was (Author: ehugonnet): This has nothing to do with the CLI nor the ordering of operations on the server side, so I'm decreasing the priority. This behaviour is incorrect but there is a simple workaround using --force in the deploy command to avoid it. With the fix, you'll need to start the deployment : {code} batch undeploy example.war --server-groups=main-server-group deploy /PATH/TO/example.war --name=example.war --server-groups=main-server-group run-batch /server-group=main-server-group/deployment=example.war:deploy {code} > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 06:25:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 06:25:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3847) AS7BindingRegistry does not respect the SPI contract In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020743#comment-13020743 ] RH Bugzilla Integration commented on WFLY-3847: ----------------------------------------------- Ond?ej Kalman changed the Status of [bug 1124178|https://bugzilla.redhat.com/show_bug.cgi?id=1124178] from ASSIGNED to VERIFIED > AS7BindingRegistry does not respect the SPI contract > ---------------------------------------------------- > > Key: WFLY-3847 > URL: https://issues.jboss.org/browse/WFLY-3847 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 8.1.0.Final > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Minor > Fix For: 9.0.0.Alpha1 > > > The implementation of AS7BindingRegistry#lookup always return null. > This method is called by HornetQ when JNDI entries for its resources > are updated using its own management API. > We advise against using it in WildFly (and use WildFly own management API) but we must still respect the SPI contract for this method. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 06:30:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 06:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3974) Move 'Channel end notification received, closing channel' to DEBUG In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020746#comment-13020746 ] RH Bugzilla Integration commented on WFLY-3974: ----------------------------------------------- Ond?ej Kalman changed the Status of [bug 1147506|https://bugzilla.redhat.com/show_bug.cgi?id=1147506] from MODIFIED to VERIFIED > Move 'Channel end notification received, closing channel' to DEBUG > ------------------------------------------------------------------ > > Key: WFLY-3974 > URL: https://issues.jboss.org/browse/WFLY-3974 > Project: WildFly > Issue Type: Enhancement > Components: Naming > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 9.0.0.Beta1 > > > When a remote jms queue is located the following is seen: > 2014-09-25 16:48:29,327 INFO [org.jboss.as.naming] (Remoting "jeev6dev01_200" task-1) JBAS011806: Notification de fin de canal re?ue, fermeture du canal Channel ID 0cb79bd5 (inbound) of Remoting connection 53a1933a to /10.23.132.245:57733 > This is due to org.jboss.as.naming.NamingLogger where the following is used: > @LogMessage(level=Logger.Level.INFO) > @Message(id=11806, value="Channel end notification received, closing channel %s") > public abstract void closingChannelOnChannelEnd(Channel paramChannel); > Changin this to > @LogMessage(level=Logger.Level.DEBUG) > Would ensure that an INFO log event is not seen every time a jms message is sent to the server. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 06:51:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 06:51:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020752#comment-13020752 ] RH Bugzilla Integration commented on WFLY-4089: ----------------------------------------------- R?my Maucherat changed the Status of [bug 1164600|https://bugzilla.redhat.com/show_bug.cgi?id=1164600] from POST to NEW > ServletContainerInitializerDeploymentProcessor does not handle comments > ----------------------------------------------------------------------- > > Key: WFLY-4089 > URL: https://issues.jboss.org/browse/WFLY-4089 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: James Livingston > Assignee: Stuart Douglas > > ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. > The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. > Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 07:01:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 07:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-795) jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020757#comment-13020757 ] RH Bugzilla Integration commented on WFLY-795: ---------------------------------------------- Stefan Guilhen changed the Status of [bug 1028412|https://bugzilla.redhat.com/show_bug.cgi?id=1028412] from ASSIGNED to POST > jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements > -------------------------------------------------------------------------------------- > > Key: WFLY-795 > URL: https://issues.jboss.org/browse/WFLY-795 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: James Livingston > Assignee: David Lloyd > Fix For: 8.0.0.CR1 > > > In jboss-ejb-iiop_1_0.xsd, the "integrity", "confidentiality", "establish-trust-in-client", and "establish-trust-in-target" attributes on the "iorTransportConfigType" complexType, and the "auth-method", "realm" and "required" attributes on the "iorASContextType" complexType have both use="required" and a default attribute. > This does not make sense because default values are only applicable to optional attributes. I'm not sure which is correct, but either the attributes should be optional or the default values removed. This problem causes the XSD to not validate. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 07:08:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 07:08:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020762#comment-13020762 ] RH Bugzilla Integration commented on WFLY-4089: ----------------------------------------------- Radim Hatlapatka changed the Status of [bug 1164600|https://bugzilla.redhat.com/show_bug.cgi?id=1164600] from NEW to POST > ServletContainerInitializerDeploymentProcessor does not handle comments > ----------------------------------------------------------------------- > > Key: WFLY-4089 > URL: https://issues.jboss.org/browse/WFLY-4089 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: James Livingston > Assignee: Stuart Douglas > > ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. > The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. > Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 07:17:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Tue, 18 Nov 2014 07:17:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020529#comment-13020529 ] Emmanuel Hugonnet edited comment on WFCORE-242 at 11/18/14 7:17 AM: -------------------------------------------------------------------- This has nothing to do with the CLI nor the ordering of operations on the server side, so I'm decreasing the priority. This behaviour is incorrect but there is a simple workaround using --force in the deploy command to avoid it. With the fix, you'll need to start the deployment after the batch : {code} batch undeploy example.war --server-groups=main-server-group deploy /PATH/TO/example.war --name=example.war --server-groups=main-server-group /server-group=main-server-group/deployment=example.war:redeploy run-batch {code} was (Author: ehugonnet): This has nothing to do with the CLI nor the ordering of operations on the server side, so I'm decreasing the priority. This behaviour is incorrect but there is a simple workaround using --force in the deploy command to avoid it. With the fix, you'll need to start the deployment after the batch : {code} batch undeploy example.war --server-groups=main-server-group deploy /PATH/TO/example.war --name=example.war --server-groups=main-server-group run-batch /server-group=main-server-group/deployment=example.war:deploy {code} > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 07:17:40 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Tue, 18 Nov 2014 07:17:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020529#comment-13020529 ] Emmanuel Hugonnet edited comment on WFCORE-242 at 11/18/14 7:17 AM: -------------------------------------------------------------------- This has nothing to do with the CLI nor the ordering of operations on the server side, so I'm decreasing the priority. This behaviour is incorrect but there is a simple workaround using --force in the deploy command to avoid it. With the fix, you'll need to start the deployment after the batch : {code} batch undeploy example.war --server-groups=main-server-group deploy /PATH/TO/example.war --name=example.war --server-groups=main-server-group /server-group=main-server-group/deployment=example.war:redeploy run-batch {code} was (Author: ehugonnet): This has nothing to do with the CLI nor the ordering of operations on the server side, so I'm decreasing the priority. This behaviour is incorrect but there is a simple workaround using --force in the deploy command to avoid it. With the fix, you'll need to start the deployment after the batch : {code} batch undeploy example.war --server-groups=main-server-group deploy /PATH/TO/example.war --name=example.war --server-groups=main-server-group /server-group=main-server-group/deployment=example.war:redeploy run-batch {code} > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 07:18:39 2014 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Tue, 18 Nov 2014 07:18:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4093) Changing IOR settings should require restart of jacorb subsystem In-Reply-To: References: Message-ID: Stefan Guilhen created WFLY-4093: ------------------------------------ Summary: Changing IOR settings should require restart of jacorb subsystem Key: WFLY-4093 URL: https://issues.jboss.org/browse/WFLY-4093 Project: WildFly Issue Type: Bug Components: IIOP Affects Versions: 9.0.0.Alpha1 Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: 9.0.0.Beta1 When using management operations to add IOR settings, the settings don't get reflected in the IORSecConfigMetaDataService until a server reload. The management operations should mark that the jacorb subsystem needs to be restarted. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 07:34:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 07:34:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4093) Changing IOR settings should require restart of jacorb subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4093: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1080333 > Changing IOR settings should require restart of jacorb subsystem > ---------------------------------------------------------------- > > Key: WFLY-4093 > URL: https://issues.jboss.org/browse/WFLY-4093 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 9.0.0.Alpha1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: 9.0.0.Beta1 > > > When using management operations to add IOR settings, the settings don't get reflected in the IORSecConfigMetaDataService until a server reload. The management operations should mark that the jacorb subsystem needs to be restarted. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 07:50:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 07:50:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4093) Changing IOR settings should require restart of jacorb subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020774#comment-13020774 ] RH Bugzilla Integration commented on WFLY-4093: ----------------------------------------------- Stefan Guilhen changed the Status of [bug 1080333|https://bugzilla.redhat.com/show_bug.cgi?id=1080333] from NEW to POST > Changing IOR settings should require restart of jacorb subsystem > ---------------------------------------------------------------- > > Key: WFLY-4093 > URL: https://issues.jboss.org/browse/WFLY-4093 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 9.0.0.Alpha1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: 9.0.0.Beta1 > > > When using management operations to add IOR settings, the settings don't get reflected in the IORSecConfigMetaDataService until a server reload. The management operations should mark that the jacorb subsystem needs to be restarted. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:03:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 18 Nov 2014 08:03:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-260) Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-260: ------------------------------------ Summary: Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab (was: Kerberos authentication not working on the IBM JVM) > Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab > ------------------------------------------------------------------------------------------ > > Key: WFCORE-260 > URL: https://issues.jboss.org/browse/WFCORE-260 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha13 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:08:40 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 18 Nov 2014 08:08:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-647) memory leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-647. -------------------------------- Fix Version/s: 6.2.0.CR3 Resolution: Cannot Reproduce Bug I ran your test case against the master branch, but couldn't reproduce any leak. In particular I printed the whole JVM heap after its execution and I am pasting it below. As you can see, after the 10,000 loops of your test there is only one instance for each com.sample.OprOBActionGroupSOsIntoIOPs, com.sample.OprOBProductCodeProductType, com.sample.OprOBServiceOrder and com.sample.ServiceOrder and 2 of com.sample.OprOBBusAct and com.sample.BusinessActivity and this happens simply because the last loop doesn't trigger a fireAllRules after having deleted them from the ksession. I believe this leak has been already fixed by a former commit. num #instances #bytes class name ---------------------------------------------- 1: 1930 8446120 [S 2: 17305 1367520 [C 3: 4222 453592 java.lang.Class 4: 16545 397080 java.lang.String 5: 547 260192 [B 6: 5843 186976 java.util.concurrent.ConcurrentHashMap$Node 7: 2095 146968 [Ljava.lang.Object; 8: 4573 146336 java.util.HashMap$Node 9: 1174 103312 java.lang.reflect.Method 10: 1814 92464 [I 11: 5494 87904 java.lang.Object 12: 502 87368 [Ljava.util.HashMap$Node; 13: 2036 81440 java.util.LinkedHashMap$Entry 14: 1268 61184 [Ljava.lang.String; 15: 572 41184 java.lang.reflect.Field 16: 1174 39240 [J 17: 54 39040 [Ljava.util.concurrent.ConcurrentHashMap$Node; 18: 674 32352 java.util.HashMap 19: 1211 26128 [Ljava.lang.Class; 20: 304 24320 java.lang.reflect.Constructor 21: 105 21000 com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDecl 22: 1165 18640 org.antlr.runtime.BitSet 23: 582 18624 java.util.Hashtable$Entry 24: 225 12600 java.lang.Class$ReflectionData 25: 173 12456 org.mvel2.ast.ASTNode 26: 341 10912 sun.misc.FDBigInteger 27: 214 10272 org.mvel2.templates.res.TextNode 28: 242 9680 java.lang.ref.SoftReference 29: 29 9488 [Lorg.drools.core.util.Entry; 30: 166 9296 java.lang.Package 31: 62 9112 [Lcom.sun.org.apache.xerces.internal.util.SymbolHash$Entry; 32: 25 7704 [[S 33: 60 7088 [Ljava.util.Hashtable$Entry; 34: 291 6984 java.util.jar.Attributes$Name 35: 109 6976 java.net.URL 36: 418 6688 java.lang.Integer 37: 68 6376 [Ljava.lang.reflect.Method; 38: 243 5832 com.sun.org.apache.xerces.internal.util.SymbolHash$Entry 39: 142 5680 java.lang.ref.Finalizer 40: 160 5120 org.mvel2.compiler.ExecutableAccessor 41: 60 4816 [Ljava.util.WeakHashMap$Entry; 42: 187 4488 java.util.ArrayList 43: 69 4416 java.util.concurrent.ConcurrentHashMap 44: 86 4128 org.mvel2.templates.res.CompiledExpressionNode 45: 256 4096 java.lang.Short 46: 91 3640 java.math.BigInteger 47: 88 3608 [Ljava.lang.reflect.Field; 48: 146 3520 [Ljava.lang.reflect.Constructor; 49: 62 3472 java.util.zip.ZipFile$ZipFileInputStream 50: 47 3384 org.mvel2.ast.OperatorNode 51: 140 3360 sun.reflect.NativeConstructorAccessorImpl 52: 36 3168 org.mvel2.ast.BinaryOperation 53: 63 3024 org.mvel2.templates.res.TerminalNode 54: 8 3008 java.lang.Thread 55: 60 2880 java.util.WeakHashMap 56: 23 2848 [Z 57: 27 2808 org.mvel2.ParserContext 58: 39 2808 org.mvel2.ast.LiteralNode 59: 82 2776 [[C 60: 27 2592 org.mvel2.compiler.ExpressionCompiler 61: 64 2560 java.util.TreeMap$Entry 62: 3 2520 [[Ljava.lang.String; 63: 51 2448 sun.util.locale.LocaleObjectCache$CacheEntry 64: 76 2432 java.util.Vector 65: 25 2400 sun.util.calendar.Gregorian$Date 66: 33 2376 org.mvel2.templates.res.CompiledForEachNode 67: 49 2352 sun.misc.URLClassPath$JarLoader 68: 42 2352 sun.nio.cs.UTF_8$Encoder 69: 143 2288 sun.reflect.DelegatingConstructorAccessorImpl 70: 69 2208 java.lang.ref.ReferenceQueue 71: 38 2128 java.util.LinkedHashMap 72: 85 2040 org.mvel2.util.ExecutionStack 73: 31 1984 java.util.jar.JarFile 74: 20 1920 java.util.jar.JarFile$JarFileEntry 75: 39 1872 java.util.Hashtable 76: 1 1712 [[B 77: 30 1680 java.security.Provider$Service 78: 69 1656 java.security.Provider$ServiceKey 79: 41 1640 java.io.ObjectStreamField 80: 84 1632 [Lorg.drools.core.rule.Declaration; 81: 51 1632 org.drools.core.base.AccessorKey 82: 40 1600 java.security.ProtectionDomain 83: 25 1600 org.drools.core.base.mvel.MVELCompilationUnit 84: 33 1584 com.sun.org.apache.xerces.internal.impl.dv.xs.DecimalDV$XDecimal 85: 22 1584 org.drools.core.rule.constraint.MvelConstraint 86: 97 1552 java.util.HashSet 87: 48 1536 com.sun.org.apache.xerces.internal.impl.xs.traversers.OneAttr 88: 63 1512 com.thoughtworks.xstream.core.util.PrioritizedList$PrioritizedItem 89: 62 1488 com.sun.org.apache.xerces.internal.util.SymbolHash 90: 46 1472 com.sun.org.apache.xerces.internal.util.SymbolTable$Entry 91: 16 1408 org.drools.compiler.lang.descr.PatternDescr 92: 25 1400 org.drools.compiler.lang.descr.ExprConstraintDescr 93: 1 1376 [Lsun.misc.FDBigInteger; 94: 23 1288 org.mvel2.templates.res.CompiledIfNode 95: 40 1280 java.security.CodeSource 96: 32 1280 java.util.WeakHashMap$Entry 97: 41 1264 [Lcom.sun.org.apache.xerces.internal.impl.xs.traversers.OneAttr; 98: 2 1264 com.sample.BusinessActivity 99: 26 1248 com.sun.org.apache.xerces.internal.impl.xs.XSAttributeDecl 100: 38 1216 java.util.zip.ZipCoder 101: 50 1200 org.drools.core.base.evaluators.Operator 102: 38 1184 [Ljava.math.BigInteger; 103: 36 1152 sun.reflect.UnsafeStaticObjectFieldAccessorImpl 104: 71 1136 java.lang.ref.ReferenceQueue$Lock 105: 19 1064 org.drools.compiler.lang.descr.AndDescr 106: 19 1064 org.drools.core.rule.Pattern 107: 22 1056 java.util.zip.Inflater 108: 1 1040 [Ljava.lang.Integer; 109: 1 1040 [Ljava.lang.Short; 110: 26 1040 org.drools.core.rule.Declaration 111: 10 1040 org.drools.core.rule.TypeDeclaration 112: 26 1040 org.mvel2.ParserConfiguration 113: 18 1008 java.util.ResourceBundle$CacheKey 114: 25 1000 sun.util.locale.BaseLocale$Key 115: 30 960 java.security.Provider$EngineDescription 116: 24 960 java.util.IdentityHashMap 117: 13 936 com.sun.org.apache.xerces.internal.impl.xs.XSElementDecl 118: 38 912 java.util.ArrayDeque 119: 19 912 java.util.Properties 120: 36 864 com.sun.org.apache.xerces.internal.impl.xs.traversers.SmallContainer 121: 36 864 java.util.Date 122: 18 864 java.util.ResourceBundle$BundleReference 123: 12 864 java.util.regex.Pattern 124: 12 864 org.drools.core.common.PhreakPropagationContext 125: 26 832 com.sun.org.apache.xerces.internal.impl.xs.XSAttributeUseImpl 126: 13 832 com.sun.org.apache.xerces.internal.impl.xs.XSComplexTypeDecl 127: 25 800 java.util.Locale 128: 25 800 sun.util.locale.BaseLocale 129: 33 792 [Ljava.io.Serializable; 130: 9 792 org.drools.core.reteoo.RightTuple 131: 33 792 org.mvel2.compiler.ExecutableLiteral 132: 49 784 java.util.jar.Attributes 133: 7 784 org.drools.core.reteoo.JoinNode 134: 19 760 com.sun.org.apache.xerces.internal.impl.xs.XSParticleDecl 135: 9 720 org.drools.core.common.DefaultFactHandle 136: 9 720 org.mvel2.ast.And 137: 1 712 [Lcom.sun.org.apache.xerces.internal.util.SymbolTable$Entry; 138: 11 704 org.drools.core.reteoo.BetaMemory 139: 29 696 org.drools.core.base.ValueType 140: 21 672 java.io.File 141: 28 672 java.security.Provider$UString 142: 7 672 org.drools.core.reteoo.JoinNodeLeftTuple 143: 21 672 org.kie.api.io.ResourceType 144: 9 648 org.drools.core.reteoo.ObjectTypeNode 145: 9 648 sun.reflect.DelegatingClassLoader 146: 40 640 [Ljava.security.Principal; 147: 40 640 java.security.ProtectionDomain$Key 148: 20 640 org.drools.core.base.ClassObjectType 149: 4 624 [D 150: 13 624 com.sun.org.apache.xerces.internal.impl.xs.XSAttributeGroupDecl 151: 39 624 java.util.regex.Pattern$CharPropertyNames$1 152: 39 624 org.drools.core.base.evaluators.TimeIntervalParser 153: 11 616 sun.util.calendar.ZoneInfo 154: 25 600 java.util.Locale$LocaleKey 155: 36 576 java.util.HashMap$KeySet 156: 18 576 java.util.ResourceBundle$LoaderReference 157: 6 576 org.drools.core.common.ProjectClassLoader 158: 35 560 java.util.concurrent.atomic.AtomicInteger 159: 7 560 sun.net.www.protocol.jar.URLJarFile 160: 23 552 com.sun.org.apache.xerces.internal.impl.xs.util.XSObjectListImpl 161: 22 528 com.thoughtworks.xstream.io.xml.XmlFriendlyNameCoder$IntPair 162: 33 528 java.util.concurrent.atomic.AtomicBoolean 163: 22 528 java.util.zip.ZStreamRef 164: 11 528 org.drools.core.common.SynchronizedRightTupleSets 165: 22 528 org.mvel2.optimizers.impl.refl.nodes.VariableAccessor 166: 13 520 org.drools.core.rule.constraint.ConditionAnalyzer$AritmeticOperator 167: 8 512 java.nio.DirectByteBuffer 168: 16 512 java.util.Collections$SynchronizedMap 169: 8 512 org.drools.core.reteoo.AlphaNode 170: 7 480 [[I 171: 3 480 com.sun.org.apache.xerces.internal.impl.xs.SchemaGrammar$BuiltinSchemaGrammar 172: 6 480 com.sun.org.apache.xerces.internal.impl.xs.models.XSDFACM 173: 12 480 java.security.AccessControlContext 174: 15 480 java.util.regex.Pattern$Curly 175: 10 480 org.drools.core.util.asm.ClassFieldInspector 176: 16 456 [Ljava.io.ObjectStreamField; 177: 28 448 java.util.HashMap$EntrySet 178: 14 448 java.util.concurrent.locks.ReentrantLock$NonfairSync 179: 7 448 org.drools.compiler.lang.descr.AttributeDescr 180: 8 448 org.drools.core.util.index.LeftTupleIndexHashTable 181: 8 448 org.drools.core.util.index.RightTupleIndexHashTable 182: 27 432 com.thoughtworks.xstream.converters.SingleValueConverterWrapper 183: 18 432 java.text.DateFormat$Field 184: 9 432 org.drools.core.reteoo.ClassObjectTypeConf 185: 9 432 org.drools.core.util.index.RightTupleList 186: 13 424 [Lcom.sun.org.apache.xerces.internal.impl.xs.XSAttributeUseImpl; 187: 4 416 com.sun.org.apache.xerces.internal.impl.dv.xs.AbstractDateTimeDV$DateTimeData 188: 13 416 java.io.FileDescriptor 189: 26 416 java.util.HashMap$Values 190: 13 416 org.drools.core.rule.constraint.MvelConstraint$MvelContextEntry 191: 26 416 org.eclipse.jdt.internal.compiler.impl.IrritantSet 192: 17 408 java.lang.Class$AnnotationData 193: 17 408 org.drools.compiler.rule.builder.dialect.java.parser.JavaBlockDescr$BlockType 194: 25 400 [Lorg.drools.core.base.EvaluatorWrapper; 195: 10 400 com.sun.org.apache.xerces.internal.impl.xpath.regex.RangeToken 196: 10 400 org.drools.core.util.index.LeftTupleList 197: 7 392 org.mvel2.templates.res.CompiledDeclareNode 198: 12 384 java.io.FilePermission 199: 1 384 java.lang.ref.Finalizer$FinalizerThread 200: 12 384 java.security.BasicPermissionCollection 201: 12 384 java.security.Permissions 202: 16 384 org.drools.compiler.lang.DroolsParaphraseTypes 203: 4 384 org.drools.core.definitions.impl.KnowledgePackageImpl 204: 4 384 org.drools.core.reteoo.SegmentMemory 205: 8 384 org.mvel2.templates.res.EndNode 206: 1 376 java.lang.ref.Reference$ReferenceHandler 207: 23 368 java.awt.font.TextAttribute 208: 15 360 java.lang.RuntimePermission 209: 15 360 org.drools.core.base.ClassFieldAccessorCache$ClassObjectTypeKey 210: 15 360 org.drools.core.base.ClassFieldAccessorStore$FieldLookupEntry 211: 15 360 org.drools.core.base.ClassFieldReader 212: 3 360 org.drools.core.definitions.rule.impl.RuleImpl 213: 9 360 org.drools.core.util.ObjectHashSet 214: 5 360 org.mvel2.ast.Substatement 215: 15 360 sun.misc.MetaIndex 216: 22 352 java.lang.Float 217: 11 352 org.drools.core.rule.GroupElement 218: 8 344 [Lcom.sun.org.apache.xerces.internal.impl.xs.util.SimpleLocator; 219: 6 336 java.nio.DirectLongBufferU 220: 14 336 org.drools.compiler.lang.DroolsSentenceType 221: 6 336 org.drools.core.factmodel.ClassDefinition 222: 3 336 org.drools.core.reteoo.NotNodeLeftTuple 223: 6 336 sun.management.MemoryPoolImpl 224: 7 336 sun.util.locale.provider.LocaleResources$ResourceReference 225: 8 320 com.thoughtworks.xstream.core.util.Pool 226: 4 320 org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader 227: 10 320 org.drools.core.spi.PatternExtractor 228: 10 320 org.drools.core.util.AbstractHashTable$SingleIndex 229: 10 320 org.eclipse.jdt.internal.compiler.lookup.BaseTypeBinding 230: 13 312 [Lcom.sun.org.apache.xerces.internal.impl.xs.identity.IdentityConstraint; 231: 13 312 java.util.concurrent.atomic.AtomicLong 232: 3 312 org.drools.compiler.lang.descr.RuleDescr 233: 13 312 org.drools.core.reteoo.ObjectTypeNode$Id 234: 2 304 org.drools.core.reteoo.RuleTerminalNodeLeftTuple 235: 8 288 [Ljava.lang.Boolean; 236: 4 288 [Lorg.drools.core.spi.Activation; 237: 12 288 com.sun.org.apache.xerces.internal.impl.xpath.regex.Token$CharToken 238: 12 288 java.io.FilePermissionCollection 239: 9 288 java.lang.OutOfMemoryError 240: 9 288 java.util.LinkedList 241: 12 288 java.util.jar.Manifest 242: 18 288 java.util.regex.Pattern$CharPropertyNames$4 243: 4 288 org.drools.core.base.ClassFieldAccessorCache$ByteArrayClassLoader 244: 12 288 org.drools.core.base.ClassFieldAccessorStore$ClassObjectTypeLookupEntry 245: 3 288 org.drools.core.phreak.RuleAgendaItem 246: 3 288 org.drools.core.reteoo.RuleTerminalNode 247: 12 288 org.drools.core.rule.constraint.ConditionAnalyzer$EvaluatedExpression 248: 9 288 org.mvel2.asm.Type 249: 9 288 sun.security.jca.ProviderConfig 250: 7 280 com.sun.org.apache.xerces.internal.utils.XMLSecurityManager$Limit 251: 5 272 [Lcom.sun.org.apache.xerces.internal.impl.xs.XSElementDecl; 252: 2 272 org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer 253: 17 272 sun.reflect.DelegatingMethodAccessorImpl 254: 11 264 org.drools.compiler.lang.DroolsEditorType 255: 11 264 org.drools.core.reteoo.SegmentMemory$BetaMemoryPrototype 256: 11 264 org.drools.core.reteoo.SingleLeftTupleSinkAdapter 257: 11 264 org.drools.core.util.AtomicBitwiseLong 258: 11 264 sun.jvmstat.perfdata.monitor.v2_0.TypeCode 259: 11 264 sun.reflect.NativeMethodAccessorImpl 260: 4 256 [Lcom.sun.org.apache.xerces.internal.impl.xs.XSComplexTypeDecl; 261: 8 256 java.io.FileInputStream 262: 8 256 java.lang.ThreadLocal$ThreadLocalMap$Entry 263: 4 256 org.drools.core.reteoo.SegmentMemory$Prototype 264: 16 256 org.eclipse.jdt.internal.compiler.impl.IntConstant 265: 10 240 [Lorg.drools.core.reteoo.LeftTupleSink; 266: 10 240 [Lorg.drools.core.rule.ContextEntry; 267: 10 240 java.util.LinkedList$Node 268: 3 240 org.drools.core.reteoo.KieComponentFactory 269: 2 240 org.drools.core.reteoo.NotNode 270: 10 240 org.drools.core.reteoo.SingleObjectSinkAdapter 271: 10 240 org.drools.core.rule.constraint.ConditionAnalyzer$BooleanOperator 272: 6 240 org.mvel2.compiler.CompiledExpression 273: 6 240 sun.management.MemoryPoolImpl$CollectionSensor 274: 6 240 sun.management.MemoryPoolImpl$PoolSensor 275: 4 224 com.sun.org.apache.xerces.internal.impl.xs.XSDDescription 276: 7 224 com.sun.org.apache.xerces.internal.impl.xs.XSModelGroupImpl 277: 2 224 java.net.SocksSocketImpl 278: 14 224 java.util.IdentityHashMap$KeySet 279: 14 224 java.util.LinkedHashMap$LinkedKeySet 280: 7 224 java.util.Stack 281: 14 224 java.util.concurrent.locks.ReentrantLock 282: 4 224 org.drools.core.rule.MVELDialectRuntimeData 283: 7 224 org.drools.core.rule.constraint.ConditionAnalyzer$SingleCondition 284: 9 216 java.util.regex.Pattern$Single 285: 9 216 org.drools.core.reteoo.ObjectTypeNode$IdGenerator 286: 9 216 org.drools.core.rule.constraint.MvelConstraint$1 287: 7 208 [Lcom.sun.org.apache.xerces.internal.xs.XSObject; 288: 2 208 org.drools.core.RuleBaseConfiguration 289: 13 208 org.kie.internal.utils.ServiceRegistryImpl$ReflectionInstantiator 290: 2 208 sun.util.calendar.ImmutableGregorianDate 291: 2 200 [Ljava.text.DateFormat$Field; 292: 5 200 java.lang.ClassLoader$NativeLibrary 293: 6 192 com.sun.org.apache.xerces.internal.impl.xpath.regex.Token$ClosureToken 294: 4 192 com.sun.org.apache.xerces.internal.impl.xs.SchemaGrammar$BuiltinAttrDecl 295: 8 192 com.thoughtworks.xstream.core.util.ThreadSafeSimpleDateFormat 296: 8 192 com.thoughtworks.xstream.core.util.ThreadSafeSimpleDateFormat$1 297: 8 192 java.math.RoundingMode 298: 4 192 java.util.concurrent.ConcurrentSkipListMap 299: 3 192 java.util.regex.Matcher 300: 8 192 java.util.regex.Pattern$5 301: 8 192 java.util.regex.Pattern$Start 302: 8 192 org.drools.core.reteoo.ObjectTypeNode$ObjectTypeNodeMemory 303: 8 192 org.drools.core.rule.constraint.ConditionAnalyzer$MethodInvocation 304: 8 192 org.drools.core.util.index.IndexUtil$ConstraintType 305: 2 192 org.eclipse.jdt.internal.compiler.CompilationResult 306: 8 192 org.mvel2.templates.CompiledTemplate 307: 3 192 sun.security.provider.NativePRNG$RandomIO 308: 7 184 [Lcom.sun.org.apache.xerces.internal.impl.xs.XSParticleDecl; 309: 11 176 com.sun.org.apache.xerces.internal.impl.xs.util.XInt 310: 1 176 org.mvel2.optimizers.impl.asm.ASMAccessorOptimizer 311: 7 168 [Lorg.drools.core.reteoo.ObjectTypeNode; 312: 1 168 [[Ljava.math.BigInteger; 313: 7 168 com.sun.org.apache.xerces.internal.util.FeatureState 314: 7 168 java.util.Collections$SynchronizedSet 315: 7 168 java.util.regex.Pattern$1 316: 7 168 java.util.regex.Pattern$BitClass 317: 7 168 java.util.regex.Pattern$GroupHead 318: 7 168 java.util.regex.Pattern$GroupTail 319: 3 168 org.drools.compiler.lang.descr.ExistsDescr 320: 3 168 org.drools.core.reteoo.PathMemory 321: 7 168 org.drools.core.util.AbstractHashTable$FieldIndex 322: 7 168 org.drools.core.util.LinkedList 323: 7 168 sun.jvmstat.monitor.Units 324: 7 168 sun.reflect.generics.tree.SimpleClassTypeSignature 325: 6 160 [Lcom.sun.org.apache.xerces.internal.xs.ShortList; 326: 2 160 [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry; 327: 1 160 com.sun.org.apache.xerces.internal.impl.xs.SchemaGrammar 328: 2 160 org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl 329: 5 160 org.drools.compiler.lang.descr.ConnectiveType 330: 5 160 org.drools.core.factmodel.ClassBuilderFactory 331: 1 160 org.drools.core.impl.StatefulKnowledgeSessionImpl 332: 4 160 org.drools.core.reteoo.CompositeObjectSinkAdapter 333: 4 160 org.drools.core.rule.JavaDialectRuntimeData 334: 4 160 org.drools.core.rule.MVELDialectRuntimeData$MapFunctionResolverFactory 335: 2 160 org.mvel2.ast.Or 336: 10 160 org.mvel2.util.SimpleVariableSpaceModel 337: 4 160 sun.reflect.UnsafeQualifiedStaticIntegerFieldAccessorImpl 338: 5 160 sun.util.locale.provider.LocaleProviderAdapter$Type 339: 1 144 com.sample.ServiceOrder 340: 6 144 com.sun.org.apache.xerces.internal.util.Status 341: 1 144 java.text.DecimalFormat 342: 9 144 java.util.LinkedHashMap$LinkedValues 343: 3 144 java.util.TreeMap 344: 6 144 java.util.concurrent.ConcurrentSkipListMap$Node 345: 6 144 java.util.regex.Pattern$CharPropertyNames$2 346: 6 144 org.drools.compiler.lang.descr.AttributeDescr$Type 347: 6 144 org.drools.core.base.field.LongFieldImpl 348: 3 144 org.drools.core.rule.PredicateConstraint 349: 6 144 org.kie.internal.utils.ChainedProperties 350: 6 144 sun.misc.PerfCounter 351: 1 136 [Lcom.sun.org.apache.xerces.internal.impl.dv.xs.TypeValidator; 352: 7 128 [Lsun.reflect.generics.tree.TypeArgument; 353: 2 128 com.sun.org.apache.xerces.internal.impl.xpath.regex.RegularExpression 354: 2 128 java.io.ExpiringCache$1 355: 8 128 java.lang.Character 356: 8 128 java.lang.ThreadLocal 357: 4 128 java.lang.ref.WeakReference 358: 4 128 java.util.concurrent.ConcurrentSkipListMap$HeadIndex 359: 8 128 java.util.regex.Pattern$CharPropertyNames$3 360: 2 128 org.drools.core.SessionConfiguration 361: 4 128 org.drools.core.base.ClassFieldAccessorCache$CacheEntry 362: 1 128 org.drools.core.reteoo.AccumulateNode 363: 8 128 org.drools.core.reteoo.AlphaNode$AlphaMemory 364: 8 128 org.mvel2.conversion.ArrayHandler 365: 2 120 [Lcom.thoughtworks.xstream.io.xml.XmlFriendlyNameCoder$IntPair; 366: 5 120 [Lorg.drools.core.reteoo.ObjectSink; 367: 1 120 com.sun.org.apache.xerces.internal.impl.XMLEntityManager 368: 5 120 com.sun.org.apache.xerces.internal.impl.xs.traversers.LargeContainer 369: 5 120 com.sun.org.apache.xerces.internal.util.PropertyState 370: 5 120 com.sun.org.apache.xerces.internal.utils.XMLSecurityManager$State 371: 5 120 com.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager$State 372: 5 120 java.util.Collections$UnmodifiableRandomAccessList 373: 5 120 java.util.concurrent.ConcurrentHashMap$KeySetView 374: 5 120 java.util.concurrent.CopyOnWriteArrayList 375: 5 120 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject 376: 5 120 java.util.regex.Pattern$CharProperty$1 377: 5 120 java.util.regex.Pattern$Slice 378: 3 120 org.drools.core.common.LeftTupleSetsImpl 379: 5 120 org.drools.core.common.SingleBetaConstraints 380: 5 120 org.drools.core.factmodel.traits.TraitMapPropertyWrapperClassBuilderImpl 381: 5 120 org.drools.core.factmodel.traits.TraitMapProxyClassBuilderImpl 382: 5 120 org.drools.core.factmodel.traits.TraitTypeEnum 383: 1 120 org.drools.core.impl.KnowledgeBaseImpl 384: 5 120 org.drools.core.reteoo.ObjectSinkNodeList 385: 3 120 org.drools.core.util.TripleStore 386: 5 120 org.mvel2.optimizers.impl.refl.nodes.GetterAccessor 387: 3 120 sun.misc.FloatingDecimal$BinaryToASCIIBuffer 388: 5 120 sun.misc.FloatingDecimal$PreparedASCIIToBinaryBuffer 389: 3 120 sun.misc.URLClassPath 390: 2 112 [Lorg.eclipse.jdt.internal.compiler.lookup.LocalVariableBinding; 391: 2 112 org.drools.compiler.lang.descr.ImportDescr 392: 2 112 org.drools.compiler.lang.descr.NotDescr 393: 2 112 org.drools.compiler.rule.builder.dialect.java.JavaDialect 394: 2 112 org.drools.compiler.rule.builder.dialect.mvel.MVELDialect 395: 1 112 org.drools.core.reteoo.ExistsNode 396: 7 112 sun.reflect.generics.tree.ClassTypeSignature 397: 1 104 org.drools.compiler.lang.descr.CompositePackageDescr 398: 1 104 org.mvel2.optimizers.dynamic.DynamicOptimizer 399: 1 96 [Lcom.sun.org.apache.xerces.internal.impl.xpath.regex.RegularExpression; 400: 1 96 [Ljava.lang.invoke.MethodType; 401: 2 96 com.sample.OprOBBusAct 402: 4 96 com.sun.org.apache.xerces.internal.impl.xpath.regex.Token$ParenToken 403: 4 96 com.sun.org.apache.xerces.internal.impl.xpath.regex.Token$UnionToken 404: 3 96 com.sun.org.apache.xerces.internal.utils.XMLSecurityManager$NameMap 405: 4 96 com.thoughtworks.xstream.converters.basic.BooleanConverter 406: 4 96 com.thoughtworks.xstream.core.util.FastField 407: 3 96 java.io.FileOutputStream 408: 2 96 java.lang.ThreadGroup 409: 4 96 java.math.MathContext 410: 2 96 java.nio.HeapByteBuffer 411: 6 96 java.util.LinkedHashSet 412: 2 96 java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync 413: 3 96 java.util.regex.Pattern$Branch 414: 4 96 java.util.regex.Pattern$Ctype 415: 2 96 org.antlr.runtime.CommonToken 416: 4 96 org.drools.compiler.commons.jci.readers.MemoryResourceReader 417: 4 96 org.drools.core.base.ClassFieldAccessorStore 418: 3 96 org.drools.core.factmodel.traits.TraitFactory 419: 3 96 org.drools.core.phreak.RuleExecutor 420: 1 96 org.drools.core.reteoo.FromNodeLeftTuple 421: 4 96 org.drools.core.reteoo.ReteooFactHandleFactory 422: 4 96 org.drools.core.reteoo.RightTupleMemory$IndexType 423: 4 96 org.drools.core.rule.DialectRuntimeRegistry 424: 4 96 org.drools.core.rule.GroupElement$Type 425: 3 96 org.drools.core.rule.PredicateConstraint$PredicateContextEntry 426: 4 96 org.drools.core.rule.constraint.ConditionAnalyzer$FieldAccessInvocation 427: 4 96 org.drools.core.util.AbstractHashTable$DoubleCompositeIndex 428: 4 96 org.drools.core.util.BinaryHeapQueue 429: 4 96 sun.jvmstat.monitor.Variability 430: 2 96 sun.nio.cs.StreamEncoder 431: 1 96 sun.security.jca.ProviderList$1 432: 1 96 sun.security.provider.Sun 433: 3 96 sun.util.locale.provider.LocaleServiceProviderPool 434: 4 88 [Lcom.sun.org.apache.xerces.internal.impl.xs.XSGroupDecl; 435: 2 88 [Lcom.sun.org.apache.xerces.internal.utils.XMLSecurityManager$State; 436: 1 88 [Lorg.drools.compiler.rule.builder.dialect.java.parser.JavaBlockDescr$BlockType; 437: 5 88 [Lorg.eclipse.jdt.internal.compiler.lookup.ReferenceBinding; 438: 1 88 com.thoughtworks.xstream.XStream 439: 1 88 org.drools.compiler.builder.impl.KnowledgeBuilderImpl 440: 1 88 org.drools.core.common.DefaultAgenda 441: 1 88 sun.misc.Launcher$AppClassLoader 442: 1 88 sun.misc.Launcher$ExtClassLoader 443: 1 80 [Ljava.lang.invoke.LambdaForm; 444: 1 80 [Ljava.util.concurrent.RunnableScheduledFuture; 445: 3 80 [Ljava.util.regex.Pattern$Node; 446: 1 80 [Lorg.drools.compiler.lang.DroolsParaphraseTypes; 447: 3 80 [Lorg.drools.core.spi.BetaNodeFieldConstraint; 448: 2 80 com.sun.org.apache.xerces.internal.impl.dv.ValidatedInfo 449: 1 80 com.thoughtworks.xstream.core.util.CompositeClassLoader 450: 5 80 com.thoughtworks.xstream.mapper.DefaultMapper 451: 2 80 java.io.BufferedWriter 452: 2 80 java.io.ExpiringCache 453: 2 80 java.lang.ClassNotFoundException 454: 2 80 java.lang.invoke.MethodType 455: 1 80 java.net.URI 456: 2 80 java.util.Locale$Category 457: 2 80 java.util.PropertyResourceBundle 458: 1 80 java.util.concurrent.ScheduledThreadPoolExecutor 459: 5 80 org.drools.core.factmodel.DefaultBeanClassBuilder 460: 5 80 org.drools.core.factmodel.DefaultEnumClassBuilder 461: 5 80 org.drools.core.factmodel.traits.TraitClassBuilderImpl 462: 2 80 org.drools.core.reteoo.CompositeObjectSinkAdapter$FieldIndex 463: 1 80 org.drools.core.reteoo.LeftInputAdapterNode 464: 1 80 org.mvel2.optimizers.dynamic.DynamicClassLoader 465: 2 80 sun.reflect.UnsafeQualifiedStaticObjectFieldAccessorImpl 466: 2 80 sun.util.calendar.Era 467: 1 72 [Lorg.drools.compiler.lang.DroolsSentenceType; 468: 3 72 [Lorg.drools.core.common.BaseNode; 469: 3 72 [Lorg.drools.core.reteoo.SegmentMemory; 470: 1 72 [Lorg.drools.core.rule.constraint.ConditionAnalyzer$AritmeticOperator; 471: 2 72 [Lsun.security.jca.ProviderConfig; 472: 1 72 java.lang.invoke.MethodTypeForm 473: 3 72 java.net.InetAddress$InetAddressHolder 474: 3 72 java.util.Arrays$ArrayList 475: 1 72 java.util.ResourceBundle$RBClassLoader 476: 1 72 java.util.concurrent.ThreadPoolExecutor 477: 3 72 java.util.concurrent.atomic.AtomicMarkableReference$Pair 478: 3 72 java.util.regex.Pattern$Category 479: 3 72 java.util.regex.Pattern$Dollar 480: 3 72 org.drools.core.BeliefSystemType 481: 3 72 org.drools.core.base.ClassFieldAccessorCache 482: 3 72 org.drools.core.base.evaluators.AfterEvaluatorDefinition 483: 3 72 org.drools.core.base.evaluators.BeforeEvaluatorDefinition 484: 3 72 org.drools.core.base.evaluators.CoincidesEvaluatorDefinition 485: 3 72 org.drools.core.base.evaluators.DuringEvaluatorDefinition 486: 3 72 org.drools.core.base.evaluators.FinishedByEvaluatorDefinition 487: 3 72 org.drools.core.base.evaluators.FinishesEvaluatorDefinition 488: 3 72 org.drools.core.base.evaluators.IncludesEvaluatorDefinition 489: 3 72 org.drools.core.base.evaluators.MeetsEvaluatorDefinition 490: 3 72 org.drools.core.base.evaluators.MetByEvaluatorDefinition 491: 3 72 org.drools.core.base.evaluators.OverlappedByEvaluatorDefinition 492: 3 72 org.drools.core.base.evaluators.OverlapsEvaluatorDefinition 493: 3 72 org.drools.core.base.evaluators.StartedByEvaluatorDefinition 494: 3 72 org.drools.core.base.evaluators.StartsEvaluatorDefinition 495: 3 72 org.drools.core.base.mvel.MVELSalienceExpression 496: 3 72 org.drools.core.rule.ConsequenceMetaData$Statement 497: 3 72 org.drools.core.rule.ConsequenceMetaData$Statement$Type 498: 3 72 org.drools.core.rule.GroupElement$Type$ScopeDelimiter 499: 3 72 org.drools.core.rule.LineMappings 500: 3 72 org.drools.core.rule.TypeDeclaration$Kind 501: 3 72 org.drools.core.spi.Constraint$ConstraintType 502: 1 72 org.eclipse.jdt.internal.compiler.flow.UnconditionalFlowInfo 503: 1 72 org.eclipse.jdt.internal.compiler.lookup.ProblemReferenceBinding 504: 3 72 org.eclipse.jdt.internal.compiler.lookup.TypeConstants$CloseMethodRecord 505: 3 72 org.kie.internal.builder.ResultSeverity 506: 3 72 org.kie.internal.builder.conf.LanguageLevelOption 507: 3 72 org.kie.internal.builder.conf.PropertySpecificOption 508: 3 72 org.kie.internal.builder.conf.SessionCacheOption 509: 3 72 sun.misc.FloatingDecimal$ExceptionalBinaryToASCIIBuffer 510: 3 72 sun.misc.Signal 511: 3 72 sun.security.provider.NativePRNG$Variant 512: 1 72 sun.util.locale.provider.JRELocaleProviderAdapter 513: 3 72 sun.util.resources.ParallelListResourceBundle$KeySet 514: 1 64 [F 515: 2 64 [Lcom.sun.org.apache.xerces.internal.impl.XMLEntityManager$CharacterBuffer; 516: 2 64 [Lcom.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager$State; 517: 2 64 [Ljava.lang.Thread; 518: 1 64 [Lorg.drools.compiler.lang.DroolsEditorType; 519: 2 64 [Lorg.kie.internal.builder.conf.LanguageLevelOption; 520: 2 64 [Lorg.kie.internal.builder.conf.PropertySpecificOption; 521: 1 64 [Lsun.jvmstat.perfdata.monitor.v2_0.TypeCode; 522: 1 64 com.sun.org.apache.xerces.internal.impl.xs.SchemaGrammar$XSAnyType 523: 2 64 com.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager$Property 524: 1 64 com.thoughtworks.xstream.mapper.AnnotationMapper 525: 2 64 java.io.PrintStream 526: 2 64 java.lang.IllegalArgumentException 527: 2 64 java.lang.StringCoding$StringEncoder 528: 2 64 java.lang.VirtualMachineError 529: 2 64 java.lang.invoke.MethodType$ConcurrentWeakInternSet$WeakEntry 530: 2 64 java.lang.ref.ReferenceQueue$Null 531: 1 64 java.security.SecureRandom 532: 1 64 java.text.DateFormatSymbols 533: 1 64 java.text.DecimalFormatSymbols 534: 4 64 java.util.concurrent.ConcurrentSkipListSet 535: 2 64 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node 536: 2 64 org.drools.compiler.commons.jci.compilers.EclipseJavaCompilerSettings 537: 2 64 org.drools.compiler.compiler.PackageRegistry 538: 1 64 org.drools.compiler.kie.builder.impl.ClasspathKieProject 539: 2 64 org.drools.compiler.kproject.ReleaseIdImpl 540: 2 64 org.drools.core.base.ClassTypeResolver 541: 2 64 org.drools.core.common.DoubleBetaConstraints 542: 1 64 org.drools.core.common.NamedEntryPoint 543: 4 64 org.drools.core.common.RuleBasePartitionId 544: 1 64 org.drools.core.impl.EnvironmentImpl$NullValueConcurrentHashMap 545: 1 64 org.drools.core.reteoo.EntryPointNode 546: 4 64 org.drools.core.rule.ImportDeclaration 547: 2 64 org.drools.core.util.AbstractHashTable$TripleCompositeIndex 548: 1 64 org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$1 549: 4 64 org.kie.internal.utils.ServiceRegistryImpl$ReturnInstance 550: 4 64 sun.net.www.protocol.jar.Handler 551: 2 64 sun.reflect.generics.repository.ClassRepository 552: 1 56 [Lcom.sun.org.apache.xerces.internal.impl.dv.XSSimpleType; 553: 1 56 [Lcom.sun.org.apache.xerces.internal.impl.xs.util.XInt; 554: 1 56 [Lorg.drools.core.rule.constraint.ConditionAnalyzer$BooleanOperator; 555: 1 56 com.sun.org.apache.xerces.internal.impl.XMLEntityScanner 556: 1 56 java.lang.invoke.MemberName 557: 1 56 org.drools.compiler.kie.builder.impl.FileKieModule 558: 1 56 org.drools.compiler.kproject.models.KieBaseModelImpl 559: 1 56 org.drools.compiler.kproject.models.KieSessionModelImpl 560: 1 56 org.drools.compiler.lang.descr.CollectDescr 561: 1 56 org.drools.core.common.AgendaGroupQueueImpl 562: 1 56 org.drools.core.reteoo.Rete 563: 1 56 sun.jvmstat.perfdata.monitor.protocol.local.LocalVmManager 564: 1 56 sun.security.provider.SHA 565: 1 48 [Lcom.sun.org.apache.xerces.internal.utils.XMLSecurityManager$Limit; 566: 3 48 [Ljava.lang.annotation.Annotation; 567: 1 48 [Ljava.math.RoundingMode; 568: 2 48 [Ljava.net.InetAddress; 569: 1 48 [Ljava.util.concurrent.TimeUnit; 570: 1 48 [Lorg.drools.core.util.index.IndexUtil$ConstraintType; 571: 3 48 [Lorg.eclipse.jdt.internal.compiler.lookup.FieldBinding; 572: 3 48 [Lorg.eclipse.jdt.internal.compiler.lookup.VariableBinding; 573: 1 48 [Lsun.jvmstat.monitor.Units; 574: 2 48 [Lsun.reflect.generics.tree.ClassTypeSignature; 575: 2 48 [Lsun.util.calendar.Era; 576: 1 48 com.sample.OprOBServiceOrder 577: 3 48 com.sun.org.apache.xerces.internal.impl.dv.dtd.ListDatatypeValidator 578: 1 48 com.sun.org.apache.xerces.internal.util.URI 579: 3 48 com.thoughtworks.xstream.converters.extended.JavaClassConverter 580: 2 48 com.thoughtworks.xstream.converters.extended.TextAttributeConverter 581: 3 48 com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker 582: 2 48 java.io.BufferedOutputStream 583: 2 48 java.io.File$PathStatus 584: 2 48 java.io.OutputStreamWriter 585: 2 48 java.lang.ThreadLocal$ThreadLocalMap 586: 2 48 java.net.Inet4Address 587: 2 48 java.net.InetAddress$Cache 588: 2 48 java.net.InetAddress$Cache$Type 589: 2 48 java.net.InetAddress$CacheEntry 590: 2 48 java.nio.charset.CoderResult 591: 3 48 java.nio.charset.CodingErrorAction 592: 3 48 java.text.AttributedCharacterIterator$Attribute 593: 2 48 java.util.BitSet 594: 3 48 java.util.ResourceBundle$NoFallbackControl 595: 3 48 java.util.concurrent.ConcurrentHashMap$ValuesView 596: 2 48 java.util.concurrent.ConcurrentLinkedQueue 597: 2 48 java.util.concurrent.ConcurrentLinkedQueue$Node 598: 1 48 java.util.concurrent.LinkedBlockingQueue 599: 3 48 java.util.concurrent.atomic.AtomicMarkableReference 600: 2 48 java.util.concurrent.locks.ReentrantReadWriteLock 601: 2 48 java.util.regex.Pattern$7 602: 3 48 java.util.regex.Pattern$Begin 603: 3 48 java.util.regex.Pattern$BranchConn 604: 3 48 java.util.regex.Pattern$Dot 605: 1 48 org.drools.compiler.builder.impl.TypeDeclarationBuilder 606: 2 48 org.drools.compiler.commons.jci.compilers.EclipseJavaCompiler 607: 1 48 org.drools.compiler.commons.jci.compilers.EclipseJavaCompilerSettings$1 608: 1 48 org.drools.compiler.kie.builder.impl.FormatsManager$1 609: 2 48 org.drools.compiler.lang.descr.ExprConstraintDescr$Type 610: 2 48 org.drools.compiler.rule.builder.DroolsCompilerComponentFactory 611: 2 48 org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration 612: 2 48 org.drools.compiler.rule.builder.dialect.java.PackageStore 613: 2 48 org.drools.compiler.rule.builder.dialect.mvel.MVELDialectConfiguration 614: 2 48 org.drools.core.base.AccessorKey$AccessorType 615: 3 48 org.drools.core.base.DefaultKnowledgeHelperFactory 616: 2 48 org.drools.core.base.evaluators.EvaluatorRegistry 617: 2 48 org.drools.core.base.evaluators.MatchesEvaluatorsDefinition$1 618: 2 48 org.drools.core.base.evaluators.SetEvaluatorsDefinition$1 619: 1 48 org.drools.core.base.evaluators.SetEvaluatorsDefinition$2 620: 2 48 org.drools.core.base.evaluators.SoundslikeEvaluatorsDefinition$1 621: 3 48 org.drools.core.base.field.BooleanFieldImpl 622: 3 48 org.drools.core.common.DefaultAgendaFactory 623: 3 48 org.drools.core.common.PhreakBeliefSystemFactory 624: 3 48 org.drools.core.common.PhreakPropagationContextFactory 625: 3 48 org.drools.core.common.PhreakWorkingMemoryFactory 626: 2 48 org.drools.core.factmodel.traits.VirtualPropertyMode 627: 1 48 org.drools.core.io.impl.ByteArrayResource 628: 3 48 org.drools.core.reteoo.ReteooRuleBuilderFactory 629: 3 48 org.drools.core.reteoo.builder.PhreakNodeFactory 630: 3 48 org.drools.core.rule.ConsequenceMetaData 631: 3 48 org.drools.core.rule.DefaultLogicTransformerFactory 632: 2 48 org.drools.core.rule.TypeDeclaration$Format 633: 2 48 org.drools.core.rule.TypeDeclaration$Nature 634: 1 48 org.drools.core.rule.builder.dialect.asm.ClassGenerator$InternalTypeResolver$1 635: 2 48 org.drools.core.rule.constraint.ConditionAnalyzer$FixedExpression 636: 2 48 org.drools.core.util.ObjectHashSet$ObjectEntry 637: 3 48 org.drools.core.util.TripleFactoryImpl 638: 3 48 org.drools.core.util.TripleStore$TripleKeyComparator 639: 1 48 org.eclipse.jdt.internal.compiler.flow.FlowContext 640: 2 48 org.eclipse.jdt.internal.compiler.impl.LongConstant 641: 1 48 org.eclipse.jdt.internal.compiler.lookup.FieldBinding 642: 1 48 org.eclipse.jdt.internal.compiler.lookup.ProblemPackageBinding 643: 2 48 org.kie.api.builder.model.KieSessionModel$KieSessionType 644: 2 48 org.kie.api.conf.DeclarativeAgendaOption 645: 2 48 org.kie.api.conf.EqualityBehaviorOption 646: 2 48 org.kie.api.conf.EventProcessingOption 647: 2 48 org.kie.api.conf.MBeansOption 648: 2 48 org.kie.api.definition.type.Role$Type 649: 2 48 org.kie.api.runtime.conf.QueryListenerOption 650: 2 48 org.kie.internal.builder.conf.RuleEngineOption 651: 2 48 org.kie.internal.conf.IndexPrecedenceOption 652: 2 48 sun.misc.NativeSignalHandler 653: 3 48 sun.reflect.BootstrapConstructorAccessorImpl 654: 2 48 sun.reflect.generics.tree.ClassSignature 655: 2 48 sun.security.jca.ProviderList 656: 2 48 sun.security.jca.ProviderList$3 657: 1 48 sun.text.resources.FormatData 658: 1 48 sun.text.resources.en.FormatData_en 659: 1 48 sun.text.resources.en.FormatData_en_US 660: 1 48 sun.util.resources.CalendarData 661: 1 48 sun.util.resources.CurrencyNames 662: 1 48 sun.util.resources.TimeZoneNames 663: 1 48 sun.util.resources.en.CalendarData_en 664: 1 48 sun.util.resources.en.CurrencyNames_en_US 665: 1 48 sun.util.resources.en.TimeZoneNames_en 666: 1 40 [Lcom.sun.org.apache.xerces.internal.util.Status; 667: 2 40 [Lcom.sun.org.apache.xerces.internal.xni.grammars.Grammar; 668: 1 40 [Lcom.thoughtworks.xstream.core.util.ThreadSafeSimpleDateFormat; 669: 1 40 [Ljava.lang.management.MemoryPoolMXBean; 670: 2 40 [Ljava.security.ProtectionDomain; 671: 1 40 [Lorg.drools.compiler.lang.descr.AttributeDescr$Type; 672: 1 40 [Lorg.drools.compiler.lang.descr.ConnectiveType; 673: 1 40 [Lorg.drools.core.factmodel.traits.TraitTypeEnum; 674: 1 40 [Lorg.eclipse.jdt.internal.compiler.codegen.BranchLabel; 675: 1 40 [Lorg.eclipse.jdt.internal.compiler.codegen.ExceptionLabel; 676: 2 40 [Lsun.reflect.generics.tree.FormalTypeParameter; 677: 1 40 [Lsun.util.locale.provider.LocaleProviderAdapter$Type; 678: 1 40 [[[C 679: 1 40 com.sun.org.apache.xerces.internal.impl.XMLEntityManager$CharacterBufferPool 680: 1 40 com.sun.org.apache.xerces.internal.impl.XMLErrorReporter 681: 1 40 com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl 682: 1 40 com.sun.org.apache.xerces.internal.utils.XMLSecurityManager 683: 1 40 com.sun.xml.internal.stream.XMLEntityStorage 684: 1 40 com.sun.xml.internal.stream.util.BufferAllocator 685: 1 40 com.thoughtworks.xstream.mapper.AttributeMapper 686: 1 40 java.io.BufferedInputStream 687: 1 40 java.text.DigitList 688: 1 40 java.util.ResourceBundle$1 689: 1 40 org.drools.compiler.kie.builder.impl.KieContainerImpl 690: 1 40 org.drools.core.base.DefaultKnowledgeHelper 691: 1 40 org.drools.core.common.SynchronizedLeftTupleSets 692: 1 40 org.drools.core.common.UpgradableReentrantReadWriteLock 693: 1 40 org.drools.core.reteoo.AccumulateNode$AccumulateContext 694: 1 40 org.drools.core.reteoo.AccumulateNode$SingleAccumulateMemory 695: 1 40 org.drools.core.reteoo.LeftInputAdapterNode$LiaNodeMemory 696: 1 40 org.drools.core.util.ObjectHashMap 697: 1 40 sun.jvmstat.perfdata.monitor.protocol.local.MonitoredHostProvider 698: 1 40 sun.misc.Cleaner 699: 1 40 sun.nio.cs.StandardCharsets$Aliases 700: 1 40 sun.nio.cs.StandardCharsets$Cache 701: 1 40 sun.nio.cs.StandardCharsets$Classes 702: 1 40 sun.nio.cs.UTF_8$Decoder 703: 1 40 sun.tools.attach.LinuxVirtualMachine 704: 1 32 [Lcom.sun.org.apache.xerces.internal.impl.dv.xs.AbstractDateTimeDV$DateTimeData; 705: 1 32 [Lcom.sun.org.apache.xerces.internal.utils.XMLSecurityManager$NameMap; 706: 1 32 [Lcom.thoughtworks.xstream.core.util.FastField; 707: 2 32 [Ljava.lang.Enum; 708: 1 32 [Ljava.lang.OutOfMemoryError; 709: 2 32 [Ljava.lang.StackTraceElement; 710: 1 32 [Ljava.lang.ThreadGroup; 711: 1 32 [Lorg.drools.core.BeliefSystemType; 712: 1 32 [Lorg.drools.core.TimerJobFactoryType; 713: 1 32 [Lorg.drools.core.reteoo.RightTupleMemory$IndexType; 714: 1 32 [Lorg.drools.core.rule.ConsequenceMetaData$Statement$Type; 715: 1 32 [Lorg.drools.core.rule.GroupElement$Type$ScopeDelimiter; 716: 1 32 [Lorg.drools.core.rule.GroupElement$Type; 717: 1 32 [Lorg.drools.core.rule.TypeDeclaration$Kind; 718: 1 32 [Lorg.drools.core.spi.Constraint$ConstraintType; 719: 2 32 [Lorg.eclipse.jdt.internal.compiler.lookup.MethodBinding; 720: 2 32 [Lorg.eclipse.jdt.internal.compiler.lookup.TypeBinding; 721: 1 32 [Lorg.eclipse.jdt.internal.compiler.lookup.TypeConstants$CloseMethodRecord; 722: 1 32 [Lorg.kie.internal.builder.ResultSeverity; 723: 1 32 [Lorg.kie.internal.builder.conf.SessionCacheOption; 724: 1 32 [Lsun.jvmstat.monitor.Variability; 725: 1 32 [Lsun.security.provider.NativePRNG$Variant; 726: 2 32 com.sample.OprAutomatedActivityGraphConstructionPacket 727: 1 32 com.sun.org.apache.xerces.internal.impl.XMLEntityScanner$1 728: 2 32 com.sun.org.apache.xerces.internal.impl.dv.dtd.ENTITYDatatypeValidator 729: 2 32 com.sun.org.apache.xerces.internal.impl.dv.xs.QNameDV 730: 2 32 com.sun.org.apache.xerces.internal.impl.xpath.regex.Token 731: 2 32 com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl 732: 1 32 com.sun.org.apache.xerces.internal.jaxp.validation.SimpleXMLSchema 733: 1 32 com.sun.org.apache.xerces.internal.util.AugmentationsImpl$SmallContainer 734: 1 32 com.sun.org.apache.xerces.internal.util.XMLResourceIdentifierImpl 735: 2 32 com.thoughtworks.xstream.converters.basic.ByteConverter 736: 1 32 com.thoughtworks.xstream.converters.basic.DateConverter 737: 1 32 com.thoughtworks.xstream.converters.extended.LookAndFeelConverter 738: 1 32 com.thoughtworks.xstream.converters.reflection.ReflectionConverter 739: 1 32 com.thoughtworks.xstream.converters.reflection.SerializableConverter 740: 1 32 com.thoughtworks.xstream.io.xml.XmlFriendlyNameCoder 741: 1 32 com.thoughtworks.xstream.mapper.ClassAliasingMapper 742: 1 32 com.thoughtworks.xstream.mapper.FieldAliasingMapper 743: 1 32 java.io.UnixFileSystem 744: 1 32 java.lang.ArithmeticException 745: 2 32 java.lang.Boolean 746: 1 32 java.lang.ClassCastException 747: 1 32 java.lang.NullPointerException 748: 1 32 java.lang.StringCoding$StringDecoder 749: 1 32 java.net.Socket 750: 2 32 java.nio.ByteOrder 751: 1 32 java.security.MessageDigest$Delegate 752: 2 32 java.util.IdentityHashMap$EntrySet 753: 2 32 java.util.LinkedHashMap$LinkedEntrySet 754: 2 32 java.util.ResourceBundle$SingleFormatControl 755: 2 32 java.util.WeakHashMap$KeySet 756: 1 32 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue 757: 1 32 java.util.concurrent.ThreadLocalRandom 758: 2 32 java.util.concurrent.atomic.AtomicReference 759: 1 32 java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl 760: 2 32 java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock 761: 2 32 java.util.concurrent.locks.ReentrantReadWriteLock$Sync$ThreadLocalHoldCounter 762: 2 32 java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock 763: 1 32 java.util.regex.Pattern$BnM 764: 2 32 java.util.regex.Pattern$Caret 765: 2 32 javax.xml.validation.SecuritySupport 766: 2 32 org.drools.compiler.compiler.DialectCompiletimeRegistry 767: 2 32 org.drools.compiler.kie.builder.impl.KieRepositoryImpl$ComparableVersion$IntegerItem 768: 1 32 org.drools.compiler.kie.builder.impl.KieServicesImpl 769: 2 32 org.drools.compiler.lang.MVELDumper 770: 2 32 org.drools.compiler.rule.builder.CollectBuilder 771: 2 32 org.drools.compiler.rule.builder.ConditionalBranchBuilder 772: 2 32 org.drools.compiler.rule.builder.DefaultConstraintBuilderFactory 773: 2 32 org.drools.compiler.rule.builder.EntryPointBuilder 774: 2 32 org.drools.compiler.rule.builder.ForallBuilder 775: 2 32 org.drools.compiler.rule.builder.GroupElementBuilder 776: 2 32 org.drools.compiler.rule.builder.NamedConsequenceBuilder 777: 2 32 org.drools.compiler.rule.builder.PatternBuilder 778: 2 32 org.drools.compiler.rule.builder.QueryBuilder 779: 2 32 org.drools.compiler.rule.builder.WindowReferenceBuilder 780: 2 32 org.drools.compiler.rule.builder.dialect.java.JavaFunctionBuilder 781: 2 32 org.drools.compiler.rule.builder.dialect.mvel.MVELEnabledBuilder 782: 2 32 org.drools.compiler.rule.builder.dialect.mvel.MVELFromBuilder 783: 2 32 org.drools.compiler.rule.builder.dialect.mvel.MVELSalienceBuilder 784: 2 32 org.drools.core.RuleBaseConfiguration$AssertBehaviour 785: 2 32 org.drools.core.RuleBaseConfiguration$SequentialAgenda 786: 2 32 org.drools.core.base.EnabledBoolean 787: 2 32 org.drools.core.base.accumulators.AverageAccumulateFunction 788: 2 32 org.drools.core.base.accumulators.BigDecimalAverageAccumulateFunction 789: 2 32 org.drools.core.base.accumulators.BigDecimalSumAccumulateFunction 790: 2 32 org.drools.core.base.accumulators.CollectListAccumulateFunction 791: 2 32 org.drools.core.base.accumulators.CollectSetAccumulateFunction 792: 2 32 org.drools.core.base.accumulators.CountAccumulateFunction 793: 2 32 org.drools.core.base.accumulators.MaxAccumulateFunction 794: 2 32 org.drools.core.base.accumulators.MinAccumulateFunction 795: 2 32 org.drools.core.base.accumulators.SumAccumulateFunction 796: 2 32 org.drools.core.base.evaluators.MatchesEvaluatorsDefinition 797: 2 32 org.drools.core.base.evaluators.SetEvaluatorsDefinition 798: 2 32 org.drools.core.base.evaluators.SoundslikeEvaluatorsDefinition 799: 1 32 org.drools.core.common.QuadroupleBetaConstraints 800: 1 32 org.drools.core.common.SingleThreadedObjectStore 801: 2 32 org.drools.core.conflict.PhreakConflictResolver 802: 1 32 org.drools.core.reteoo.ReteooBuilder 803: 2 32 org.drools.core.reteoo.builder.AccumulateBuilder 804: 1 32 org.drools.core.rule.SingleAccumulate 805: 2 32 org.drools.core.type.DateFormatsImpl 806: 1 32 org.drools.core.util.HashTableIterator 807: 2 32 org.eclipse.jdt.internal.compiler.impl.BooleanConstant 808: 1 32 org.eclipse.jdt.internal.compiler.util.HashtableOfInt 809: 2 32 org.kie.api.runtime.conf.TimedRuleExectionOption 810: 2 32 org.kie.internal.builder.conf.DefaultDialectOption 811: 2 32 org.kie.internal.runtime.conf.ForceEagerActivationOption 812: 1 32 org.kie.internal.utils.ServiceRegistryImpl 813: 2 32 org.mvel2.templates.SimpleTemplateRegistry 814: 1 32 sun.management.MemoryImpl 815: 1 32 sun.nio.cs.StandardCharsets 816: 1 32 sun.reflect.generics.reflectiveObjects.TypeVariableImpl 817: 2 32 sun.reflect.generics.tree.TypeVariableSignature 818: 1 32 sun.security.provider.SecureRandom 819: 1 32 sun.util.locale.provider.LocaleResources 820: 1 24 [Lcom.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager$Property; 821: 1 24 [Ljava.io.File$PathStatus; 822: 1 24 [Ljava.lang.invoke.MethodHandle; 823: 1 24 [Ljava.lang.reflect.TypeVariable; 824: 1 24 [Ljava.net.InetAddress$Cache$Type; 825: 1 24 [Ljava.util.Locale$Category; 826: 1 24 [Lorg.drools.compiler.lang.descr.ExprConstraintDescr$Type; 827: 1 24 [Lorg.drools.core.ClockType; 828: 1 24 [Lorg.drools.core.base.AccessorKey$AccessorType; 829: 1 24 [Lorg.drools.core.factmodel.traits.VirtualPropertyMode; 830: 1 24 [Lorg.drools.core.rule.TypeDeclaration$Format; 831: 1 24 [Lorg.drools.core.rule.TypeDeclaration$Nature; 832: 1 24 [Lorg.drools.core.spi.AlphaNodeFieldConstraint; 833: 1 24 [Lorg.kie.api.builder.model.KieSessionModel$KieSessionType; 834: 1 24 [Lorg.kie.api.conf.DeclarativeAgendaOption; 835: 1 24 [Lorg.kie.api.conf.EqualityBehaviorOption; 836: 1 24 [Lorg.kie.api.conf.EventProcessingOption; 837: 1 24 [Lorg.kie.api.conf.MBeansOption; 838: 1 24 [Lorg.kie.api.definition.type.Role$Type; 839: 1 24 [Lorg.kie.api.marshalling.ObjectMarshallingStrategy; 840: 1 24 [Lorg.kie.api.runtime.conf.QueryListenerOption; 841: 1 24 [Lorg.kie.internal.builder.conf.RuleEngineOption; 842: 1 24 [Lorg.kie.internal.conf.IndexPrecedenceOption; 843: 1 24 [Lorg.mvel2.ConversionHandler; 844: 1 24 [Lsun.launcher.LauncherHelper; 845: 1 24 [Lsun.reflect.generics.tree.FieldTypeSignature; 846: 1 24 com.sample.OprOBActionGroupSOsIntoIOPs 847: 1 24 com.sample.OprOBProductCodeProductType 848: 1 24 com.sun.org.apache.xerces.internal.impl.Constants$ArrayEnumeration 849: 1 24 com.sun.org.apache.xerces.internal.impl.xs.XSMessageFormatter 850: 1 24 com.sun.org.apache.xerces.internal.util.SymbolTable 851: 1 24 com.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager 852: 1 24 com.thoughtworks.xstream.converters.basic.StringConverter 853: 1 24 com.thoughtworks.xstream.converters.collections.CollectionConverter 854: 1 24 com.thoughtworks.xstream.converters.collections.MapConverter 855: 1 24 com.thoughtworks.xstream.converters.collections.SingletonCollectionConverter 856: 1 24 com.thoughtworks.xstream.converters.collections.SingletonMapConverter 857: 1 24 com.thoughtworks.xstream.converters.collections.TreeMapConverter 858: 1 24 com.thoughtworks.xstream.converters.collections.TreeSetConverter 859: 1 24 com.thoughtworks.xstream.converters.collections.TreeSetConverter$1 860: 1 24 com.thoughtworks.xstream.converters.enums.EnumMapConverter 861: 1 24 com.thoughtworks.xstream.converters.extended.DynamicProxyConverter 862: 1 24 com.thoughtworks.xstream.converters.extended.FontConverter 863: 1 24 com.thoughtworks.xstream.converters.extended.JavaFieldConverter 864: 1 24 com.thoughtworks.xstream.converters.extended.ThrowableConverter 865: 1 24 com.thoughtworks.xstream.converters.reflection.ExternalizableConverter 866: 1 24 com.thoughtworks.xstream.converters.reflection.FieldDictionary 867: 1 24 com.thoughtworks.xstream.converters.reflection.SunUnsafeReflectionProvider 868: 1 24 com.thoughtworks.xstream.core.DefaultConverterLookup 869: 1 24 com.thoughtworks.xstream.core.util.PrioritizedList 870: 1 24 com.thoughtworks.xstream.core.util.SelfStreamingInstanceChecker 871: 1 24 com.thoughtworks.xstream.core.util.WeakCache 872: 1 24 com.thoughtworks.xstream.io.path.Path 873: 1 24 com.thoughtworks.xstream.io.xml.DomDriver 874: 1 24 com.thoughtworks.xstream.mapper.AttributeAliasingMapper 875: 1 24 com.thoughtworks.xstream.mapper.CachingMapper 876: 1 24 com.thoughtworks.xstream.mapper.DefaultImplementationsMapper 877: 1 24 com.thoughtworks.xstream.mapper.DynamicProxyMapper 878: 1 24 com.thoughtworks.xstream.mapper.EnumMapper 879: 1 24 com.thoughtworks.xstream.mapper.ImmutableTypesMapper 880: 1 24 com.thoughtworks.xstream.mapper.ImplicitCollectionMapper 881: 1 24 com.thoughtworks.xstream.mapper.LocalConversionMapper 882: 1 24 com.thoughtworks.xstream.mapper.OuterClassMapper 883: 1 24 com.thoughtworks.xstream.mapper.PackageAliasingMapper 884: 1 24 com.thoughtworks.xstream.mapper.SecurityMapper 885: 1 24 com.thoughtworks.xstream.mapper.SystemAttributeAliasingMapper 886: 1 24 java.lang.Long 887: 1 24 java.lang.StringBuilder 888: 1 24 java.lang.invoke.LambdaForm$NamedFunction 889: 1 24 java.lang.invoke.MethodType$ConcurrentWeakInternSet 890: 1 24 java.lang.reflect.ReflectPermission 891: 1 24 java.math.MutableBigInteger 892: 1 24 java.net.Inet6AddressImpl 893: 1 24 java.net.InetAddress 894: 1 24 java.net.ServerSocket 895: 1 24 java.util.Collections$EmptyMap 896: 1 24 java.util.Collections$SetFromMap 897: 1 24 java.util.Collections$SynchronizedCollection 898: 1 24 java.util.Currency 899: 1 24 java.util.Locale$Cache 900: 1 24 java.util.ResourceBundle$Control$CandidateListCache 901: 1 24 java.util.concurrent.Executors$DefaultThreadFactory 902: 1 24 java.util.concurrent.LinkedBlockingQueue$Node 903: 1 24 java.util.concurrent.TimeUnit$1 904: 1 24 java.util.concurrent.TimeUnit$2 905: 1 24 java.util.concurrent.TimeUnit$3 906: 1 24 java.util.concurrent.TimeUnit$4 907: 1 24 java.util.concurrent.TimeUnit$5 908: 1 24 java.util.concurrent.TimeUnit$6 909: 1 24 java.util.concurrent.TimeUnit$7 910: 1 24 org.drools.base.com.sample.OprOBActionGroupSOsIntoIOPs1561063579$getObjectId 911: 1 24 org.drools.base.com.sample.OprOBActionGroupSOsIntoIOPs1561063579$getObjectId 912: 1 24 org.drools.base.com.sample.OprOBActionGroupSOsIntoIOPs1561063579$isComputed 913: 1 24 org.drools.base.com.sample.OprOBActionGroupSOsIntoIOPs1561063579$isComputed 914: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getActivityId 915: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getActivityId 916: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getAddressId 917: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getAddressId 918: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getRootId 919: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getRootId 920: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getStatus 921: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getStatus 922: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getType 923: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getType 924: 1 24 org.drools.base.com.sample.OprOBProductCodeProductType1753714541$getProductCode 925: 1 24 org.drools.base.com.sample.OprOBProductCodeProductType1753714541$getProductCode 926: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getAddressId 927: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getAddressId 928: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getDesiredScheduleTypeRD 929: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getDesiredScheduleTypeRD 930: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getInternalOrderId 931: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getInternalOrderId 932: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getInternalOrderPositionId 933: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getInternalOrderPositionId 934: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getProductCode 935: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getProductCode 936: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getUsageModeValueRD 937: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getUsageModeValueRD 938: 1 24 org.drools.base.java.util.ArrayList1627960023$size 939: 1 24 org.drools.base.java.util.ArrayList1627960023$size 940: 1 24 org.drools.compiler.builder.impl.TypeDeclarationCache 941: 1 24 org.drools.compiler.builder.impl.TypeDeclarationConfigurator 942: 1 24 org.drools.compiler.kie.builder.impl.FormatsManager 943: 1 24 org.drools.compiler.kie.builder.impl.KieRepositoryImpl 944: 1 24 org.drools.compiler.kie.builder.impl.KieRepositoryImpl$ComparableVersion 945: 1 24 org.drools.compiler.kie.builder.impl.KieRepositoryImpl$ComparableVersion$ListItem 946: 1 24 org.drools.compiler.kie.builder.impl.KieRepositoryImpl$KieModuleRepo 947: 1 24 org.drools.compiler.kie.builder.impl.ResultsImpl 948: 1 24 org.drools.compiler.kproject.models.KieModuleModelImpl 949: 1 24 org.drools.core.ClockType$1 950: 1 24 org.drools.core.ClockType$2 951: 1 24 org.drools.core.TimerJobFactoryType$1 952: 1 24 org.drools.core.TimerJobFactoryType$2 953: 1 24 org.drools.core.TimerJobFactoryType$3 954: 1 24 org.drools.core.base.MapGlobalResolver 955: 1 24 org.drools.core.base.accumulators.CollectAccumulator 956: 1 24 org.drools.core.base.evaluators.MatchesEvaluatorsDefinition$StringMatchesEvaluator 957: 1 24 org.drools.core.base.evaluators.MatchesEvaluatorsDefinition$StringNotMatchesEvaluator 958: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ArrayContainsEvaluator 959: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ArrayExcludesEvaluator 960: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BigDecimalMemberOfEvaluator 961: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BigDecimalNotMemberOfEvaluator 962: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BigIntegerMemberOfEvaluator 963: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BigIntegerNotMemberOfEvaluator 964: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BooleanMemberOfEvaluator 965: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BooleanNotMemberOfEvaluator 966: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ByteMemberOfEvaluator 967: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ByteNotMemberOfEvaluator 968: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$CharacterMemberOfEvaluator 969: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$CharacterNotMemberOfEvaluator 970: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$DateMemberOfEvaluator 971: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$DateNotMemberOfEvaluator 972: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$DoubleMemberOfEvaluator 973: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$DoubleNotMemberOfEvaluator 974: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$FloatMemberOfEvaluator 975: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$FloatNotMemberOfEvaluator 976: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$IntegerMemberOfEvaluator 977: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$IntegerNotMemberOfEvaluator 978: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$LongMemberOfEvaluator 979: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$LongNotMemberOfEvaluator 980: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ObjectContainsEvaluator 981: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ObjectExcludesEvaluator 982: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ObjectMemberOfEvaluator 983: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ObjectNotMemberOfEvaluator 984: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ShortMemberOfEvaluator 985: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ShortNotMemberOfEvaluator 986: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$StringMemberOfEvaluator 987: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$StringNotMemberOfEvaluator 988: 1 24 org.drools.core.base.evaluators.SoundslikeEvaluatorsDefinition$StringNotSoundsLikeEvaluator 989: 1 24 org.drools.core.base.evaluators.SoundslikeEvaluatorsDefinition$StringSoundsLikeEvaluator 990: 1 24 org.drools.core.common.ConcurrentNodeMemories 991: 1 24 org.drools.core.common.ObjectTypeConfigurationRegistry 992: 1 24 org.drools.core.common.UpgradableReentrantReadWriteLock$1 993: 1 24 org.drools.core.event.KieBaseEventSupport 994: 1 24 org.drools.core.impl.EnvironmentImpl 995: 1 24 org.drools.core.marshalling.impl.SerializablePlaceholderResolverStrategy 996: 1 24 org.drools.core.reteoo.CompositeLeftTupleSinkAdapter 997: 1 24 org.drools.core.reteoo.LeftTupleSinkNodeList 998: 1 24 org.drools.core.reteoo.ReteooBuilder$IdGenerator 999: 1 24 org.drools.core.reteoo.SegmentMemory$LiaMemoryPrototype 1000: 1 24 org.drools.core.rule.Collect 1001: 1 24 org.drools.core.rule.builder.dialect.asm.ClassGenerator$2 1002: 1 24 org.drools.core.rule.constraint.ConditionAnalyzer$VariableExpression 1003: 1 24 org.drools.core.time.impl.JDKTimerService 1004: 1 24 org.eclipse.jdt.internal.compiler.impl.DoubleConstant 1005: 1 24 org.kie.internal.runtime.beliefs.KieBeliefsImpl 1006: 1 24 org.kie.internal.utils.ServiceRegistryImpl$FactoryInstantiator 1007: 1 24 org.mvel2.debug.DebuggerContext 1008: 1 24 org.mvel2.optimizers.impl.refl.nodes.StaticVarAccessor 1009: 1 24 sun.launcher.LauncherHelper 1010: 1 24 sun.management.RuntimeImpl 1011: 1 24 sun.management.VMManagementImpl 1012: 1 24 sun.misc.JarIndex 1013: 1 24 sun.misc.Perf$1 1014: 1 24 sun.misc.URLClassPath$FileLoader 1015: 1 24 sun.net.ProgressMonitor 1016: 1 24 sun.net.sdp.SdpProvider 1017: 1 24 sun.nio.cs.ISO_8859_1 1018: 1 24 sun.nio.cs.US_ASCII 1019: 1 24 sun.nio.cs.UTF_16 1020: 1 24 sun.nio.cs.UTF_16BE 1021: 1 24 sun.nio.cs.UTF_16LE 1022: 1 24 sun.nio.cs.UTF_8 1023: 1 24 sun.reflect.generics.factory.CoreReflectionFactory 1024: 1 24 sun.reflect.generics.scope.ClassScope 1025: 1 24 sun.reflect.generics.tree.FormalTypeParameter 1026: 1 24 sun.util.locale.BaseLocale$Cache 1027: 1 24 sun.util.locale.provider.CalendarDataProviderImpl 1028: 1 24 sun.util.locale.provider.CalendarProviderImpl 1029: 1 24 sun.util.locale.provider.CurrencyNameProviderImpl 1030: 1 24 sun.util.locale.provider.DateFormatSymbolsProviderImpl 1031: 1 24 sun.util.locale.provider.DecimalFormatSymbolsProviderImpl 1032: 1 24 sun.util.locale.provider.NumberFormatProviderImpl 1033: 1 24 sun.util.locale.provider.TimeZoneNameProviderImpl 1034: 1 16 [Lcom.sun.org.apache.xerces.internal.impl.xs.SubstitutionGroupHandler$OneSubGroup; 1035: 1 16 [Ljava.beans.EventSetDescriptor; 1036: 1 16 [Ljava.lang.Throwable; 1037: 1 16 [Ljava.security.Provider; 1038: 1 16 [Ljava.security.cert.Certificate; 1039: 1 16 [Ljava.text.FieldPosition; 1040: 1 16 [Lorg.eclipse.jdt.internal.compiler.ast.Argument; 1041: 1 16 [Lorg.eclipse.jdt.internal.compiler.ast.TypeReference; 1042: 1 16 [Lorg.eclipse.jdt.internal.compiler.classfmt.ElementValuePairInfo; 1043: 1 16 [Lorg.eclipse.jdt.internal.compiler.lookup.AnnotationBinding; 1044: 1 16 [Lorg.eclipse.jdt.internal.compiler.lookup.ElementValuePair; 1045: 1 16 [Lorg.eclipse.jdt.internal.compiler.lookup.TypeVariableBinding; 1046: 1 16 ConditionEvaluator10f8ea15999f425494040ef51fb0d217 1047: 1 16 ConditionEvaluator21d28af04cf74bfc87c007b806ddc2a1 1048: 1 16 ConditionEvaluator3c011ed3a0b042c0bd61c82573aac5db 1049: 1 16 ConditionEvaluator45f23d5af2d344da8b5ded591b4f84ca 1050: 1 16 ConditionEvaluator5957f3f8704b451fb121ede5f5d9264a 1051: 1 16 ConditionEvaluator988f236291194cefa1eecbfdf300133d 1052: 1 16 ConditionEvaluatorf6223b8bf6ca404ca7089e1a099d6ad7 1053: 1 16 com.intellij.rt.execution.application.AppMain$1 1054: 1 16 com.sample.Rule_GroupSOs_IOPExists_NotFinished_ASAP_1143440146DefaultConsequenceInvoker 1055: 1 16 com.sample.Rule_GroupSOs_IOPExists_NotFinished_ASAP_1143440146Predicate0Invoker 1056: 1 16 com.sample.Rule_GroupSOs_IOPExists_NotFinished_ASAP_1143440146Predicate0InvokerGenerated 1057: 1 16 com.sample.Rule_GroupSOs_IOPExists_NotFinished_ASAP_1143440146Predicate1Invoker 1058: 1 16 com.sample.Rule_GroupSOs_IOPExists_NotFinished_ASAP_1143440146Predicate1InvokerGenerated 1059: 1 16 com.sample.Rule_GroupSOs_NoIOP_AddrMismatch911570505DefaultConsequenceInvoker 1060: 1 16 com.sample.Rule_GroupSOs_NoIOP_AddrMismatch911570505DefaultConsequenceInvokerGenerated 1061: 1 16 com.sample.Rule_GroupSOs_NoIOP_AddrMismatch911570505Predicate0Invoker 1062: 1 16 com.sample.Rule_GroupSOs_NoIOP_AddrMismatch911570505Predicate0InvokerGenerated 1063: 1 16 com.sample.Rule_GroupSOs_NoProductType1631874407DefaultConsequenceInvoker 1064: 1 16 com.sample.SMDebugAgendaEventListener 1065: 1 16 com.sample.SMDebugWorkingMemoryEventListener 1066: 1 16 com.sun.beans.WeakCache 1067: 1 16 com.sun.naming.internal.VersionHelper12 1068: 1 16 com.sun.org.apache.xerces.internal.dom.CharacterDataImpl$1 1069: 1 16 com.sun.org.apache.xerces.internal.impl.dv.dtd.IDDatatypeValidator 1070: 1 16 com.sun.org.apache.xerces.internal.impl.dv.dtd.IDREFDatatypeValidator 1071: 1 16 com.sun.org.apache.xerces.internal.impl.dv.dtd.NMTOKENDatatypeValidator 1072: 1 16 com.sun.org.apache.xerces.internal.impl.dv.dtd.NOTATIONDatatypeValidator 1073: 1 16 com.sun.org.apache.xerces.internal.impl.dv.dtd.StringDatatypeValidator 1074: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.AnyAtomicDV 1075: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.AnySimpleDV 1076: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.AnyURIDV 1077: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.Base64BinaryDV 1078: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.BooleanDV 1079: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DateDV 1080: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DateTimeDV 1081: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DayDV 1082: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DayTimeDurationDV 1083: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DecimalDV 1084: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DoubleDV 1085: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DurationDV 1086: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.EntityDV 1087: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.FloatDV 1088: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.HexBinaryDV 1089: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.IDDV 1090: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.IDREFDV 1091: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.IntegerDV 1092: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.ListDV 1093: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.MonthDV 1094: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.MonthDayDV 1095: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.PrecisionDecimalDV 1096: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.StringDV 1097: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.TimeDV 1098: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.UnionDV 1099: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDecl$1 1100: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDecl$4 1101: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.YearDV 1102: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.YearMonthDV 1103: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.YearMonthDurationDV 1104: 1 16 com.sun.org.apache.xerces.internal.impl.xs.XSConstraints$1 1105: 1 16 com.sun.org.apache.xerces.internal.impl.xs.models.XSEmptyCM 1106: 1 16 com.sun.org.apache.xerces.internal.impl.xs.util.XIntPool 1107: 1 16 com.sun.org.apache.xerces.internal.impl.xs.util.XSObjectListImpl$1 1108: 1 16 com.sun.org.apache.xerces.internal.jaxp.validation.DraconianErrorHandler 1109: 1 16 com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory$XMLGrammarPoolWrapper 1110: 1 16 com.sun.org.apache.xerces.internal.util.AugmentationsImpl 1111: 1 16 com.sun.org.apache.xerces.internal.util.DOMEntityResolverWrapper 1112: 1 16 com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper 1113: 1 16 com.sun.org.apache.xerces.internal.utils.SecuritySupport 1114: 1 16 com.thoughtworks.xstream.XStream$1 1115: 1 16 com.thoughtworks.xstream.XStream$2 1116: 1 16 com.thoughtworks.xstream.converters.basic.BigDecimalConverter 1117: 1 16 com.thoughtworks.xstream.converters.basic.BigIntegerConverter 1118: 1 16 com.thoughtworks.xstream.converters.basic.CharConverter 1119: 1 16 com.thoughtworks.xstream.converters.basic.DoubleConverter 1120: 1 16 com.thoughtworks.xstream.converters.basic.FloatConverter 1121: 1 16 com.thoughtworks.xstream.converters.basic.IntConverter 1122: 1 16 com.thoughtworks.xstream.converters.basic.LongConverter 1123: 1 16 com.thoughtworks.xstream.converters.basic.NullConverter 1124: 1 16 com.thoughtworks.xstream.converters.basic.ShortConverter 1125: 1 16 com.thoughtworks.xstream.converters.basic.StringBufferConverter 1126: 1 16 com.thoughtworks.xstream.converters.basic.StringBuilderConverter 1127: 1 16 com.thoughtworks.xstream.converters.basic.URIConverter 1128: 1 16 com.thoughtworks.xstream.converters.basic.URLConverter 1129: 1 16 com.thoughtworks.xstream.converters.basic.UUIDConverter 1130: 1 16 com.thoughtworks.xstream.converters.collections.ArrayConverter 1131: 1 16 com.thoughtworks.xstream.converters.collections.BitSetConverter 1132: 1 16 com.thoughtworks.xstream.converters.collections.CharArrayConverter 1133: 1 16 com.thoughtworks.xstream.converters.collections.PropertiesConverter 1134: 1 16 com.thoughtworks.xstream.converters.collections.TreeMapConverter$NullComparator 1135: 1 16 com.thoughtworks.xstream.converters.enums.EnumConverter 1136: 1 16 com.thoughtworks.xstream.converters.enums.EnumSetConverter 1137: 1 16 com.thoughtworks.xstream.converters.extended.CharsetConverter 1138: 1 16 com.thoughtworks.xstream.converters.extended.ColorConverter 1139: 1 16 com.thoughtworks.xstream.converters.extended.CurrencyConverter 1140: 1 16 com.thoughtworks.xstream.converters.extended.DurationConverter 1141: 1 16 com.thoughtworks.xstream.converters.extended.DynamicProxyConverter$1 1142: 1 16 com.thoughtworks.xstream.converters.extended.EncodedByteArrayConverter 1143: 1 16 com.thoughtworks.xstream.converters.extended.FileConverter 1144: 1 16 com.thoughtworks.xstream.converters.extended.GregorianCalendarConverter 1145: 1 16 com.thoughtworks.xstream.converters.extended.JavaMethodConverter 1146: 1 16 com.thoughtworks.xstream.converters.extended.LocaleConverter 1147: 1 16 com.thoughtworks.xstream.converters.extended.RegexPatternConverter 1148: 1 16 com.thoughtworks.xstream.converters.extended.SqlDateConverter 1149: 1 16 com.thoughtworks.xstream.converters.extended.SqlTimeConverter 1150: 1 16 com.thoughtworks.xstream.converters.extended.SqlTimestampConverter 1151: 1 16 com.thoughtworks.xstream.converters.extended.StackTraceElementConverter 1152: 1 16 com.thoughtworks.xstream.converters.extended.StackTraceElementFactory15 1153: 1 16 com.thoughtworks.xstream.converters.extended.SubjectConverter 1154: 1 16 com.thoughtworks.xstream.converters.reflection.ImmutableFieldKeySorter 1155: 1 16 com.thoughtworks.xstream.converters.reflection.SerializableConverter$UnserializableParentsReflectionProvider 1156: 1 16 com.thoughtworks.xstream.core.ClassLoaderReference 1157: 1 16 com.thoughtworks.xstream.core.JVM 1158: 1 16 com.thoughtworks.xstream.core.ReferenceByXPathMarshallingStrategy 1159: 1 16 com.thoughtworks.xstream.core.util.Base64Encoder 1160: 1 16 com.thoughtworks.xstream.mapper.ArrayMapper 1161: 1 16 com.thoughtworks.xstream.mapper.PackageAliasingMapper$1 1162: 1 16 com.thoughtworks.xstream.security.AnyTypePermission 1163: 1 16 com.thoughtworks.xstream.security.NoTypePermission 1164: 1 16 java.io.FileDescriptor$1 1165: 1 16 java.lang.CharacterDataLatin1 1166: 1 16 java.lang.InheritableThreadLocal 1167: 1 16 java.lang.Runtime 1168: 1 16 java.lang.String$CaseInsensitiveComparator 1169: 1 16 java.lang.System$2 1170: 1 16 java.lang.Terminator$1 1171: 1 16 java.lang.invoke.MemberName$Factory 1172: 1 16 java.lang.ref.Reference$Lock 1173: 1 16 java.lang.reflect.ReflectAccess 1174: 1 16 java.net.InetAddress$2 1175: 1 16 java.net.URLClassLoader$7 1176: 1 16 java.nio.Bits$1 1177: 1 16 java.nio.charset.CoderResult$1 1178: 1 16 java.nio.charset.CoderResult$2 1179: 1 16 java.security.ProtectionDomain$1 1180: 1 16 java.security.ProtectionDomain$3 1181: 1 16 java.text.MessageFormat$Field 1182: 1 16 java.util.Collections$EmptyEnumeration 1183: 1 16 java.util.Collections$EmptyIterator 1184: 1 16 java.util.Collections$EmptyList 1185: 1 16 java.util.Collections$EmptySet 1186: 1 16 java.util.Collections$UnmodifiableSet 1187: 1 16 java.util.Currency$CurrencyNameGetter 1188: 1 16 java.util.EnumMap$1 1189: 1 16 java.util.Hashtable$EntrySet 1190: 1 16 java.util.Hashtable$KeySet 1191: 1 16 java.util.ResourceBundle$Control 1192: 1 16 java.util.TreeMap$KeySet 1193: 1 16 java.util.TreeSet 1194: 1 16 java.util.concurrent.ThreadPoolExecutor$AbortPolicy 1195: 1 16 java.util.concurrent.atomic.AtomicReferenceArray 1196: 1 16 java.util.jar.JavaUtilJarAccessImpl 1197: 1 16 java.util.regex.Pattern$4 1198: 1 16 java.util.regex.Pattern$CharPropertyNames$10 1199: 1 16 java.util.regex.Pattern$CharPropertyNames$11 1200: 1 16 java.util.regex.Pattern$CharPropertyNames$12 1201: 1 16 java.util.regex.Pattern$CharPropertyNames$13 1202: 1 16 java.util.regex.Pattern$CharPropertyNames$14 1203: 1 16 java.util.regex.Pattern$CharPropertyNames$15 1204: 1 16 java.util.regex.Pattern$CharPropertyNames$16 1205: 1 16 java.util.regex.Pattern$CharPropertyNames$17 1206: 1 16 java.util.regex.Pattern$CharPropertyNames$18 1207: 1 16 java.util.regex.Pattern$CharPropertyNames$19 1208: 1 16 java.util.regex.Pattern$CharPropertyNames$20 1209: 1 16 java.util.regex.Pattern$CharPropertyNames$21 1210: 1 16 java.util.regex.Pattern$CharPropertyNames$22 1211: 1 16 java.util.regex.Pattern$CharPropertyNames$23 1212: 1 16 java.util.regex.Pattern$CharPropertyNames$5 1213: 1 16 java.util.regex.Pattern$CharPropertyNames$6 1214: 1 16 java.util.regex.Pattern$CharPropertyNames$7 1215: 1 16 java.util.regex.Pattern$CharPropertyNames$8 1216: 1 16 java.util.regex.Pattern$CharPropertyNames$9 1217: 1 16 java.util.regex.Pattern$LastNode 1218: 1 16 java.util.regex.Pattern$Node 1219: 1 16 java.util.zip.ZipFile$1 1220: 1 16 javax.xml.datatype.SecuritySupport 1221: 1 16 javax.xml.parsers.SecuritySupport 1222: 1 16 org.drools.compiler.builder.impl.ClassDefinitionFactory 1223: 1 16 org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$1 1224: 1 16 org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$2 1225: 1 16 org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$3 1226: 1 16 org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$4 1227: 1 16 org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$5 1228: 1 16 org.drools.compiler.builder.impl.DeclaredClassBuilder 1229: 1 16 org.drools.compiler.builder.impl.KnowledgeBuilderFactoryServiceImpl 1230: 1 16 org.drools.compiler.builder.impl.TypeDeclarationFactory 1231: 1 16 org.drools.compiler.builder.impl.TypeDeclarationNameResolver 1232: 1 16 org.drools.compiler.commons.jci.compilers.JavaCompilerFactory 1233: 1 16 org.drools.compiler.kie.builder.impl.KieRepositoryImpl$DummyKieScanner 1234: 1 16 org.drools.compiler.kie.util.CDIHelper$ReflectionBeanCreator 1235: 1 16 org.drools.compiler.kproject.models.KieBaseModelImpl$KBaseConverter 1236: 1 16 org.drools.compiler.kproject.models.KieModuleModelImpl$kModuleConverter 1237: 1 16 org.drools.compiler.kproject.models.KieModuleModelImpl$kModuleMarshaller 1238: 1 16 org.drools.compiler.kproject.models.KieSessionModelImpl$KSessionConverter 1239: 1 16 org.drools.compiler.kproject.models.ListenerModelImpl$ListenerConverter 1240: 1 16 org.drools.compiler.kproject.models.QualifierModelImpl$QualifierConverter 1241: 1 16 org.drools.compiler.kproject.models.WorkItemHandlerModelImpl$WorkItemHandelerConverter 1242: 1 16 org.drools.compiler.rule.builder.MVELConstraintBuilder 1243: 1 16 org.drools.compiler.rule.builder.MVELConstraintBuilder$1 1244: 1 16 org.drools.compiler.rule.builder.MVELConstraintBuilder$BooleanConversionHandler 1245: 1 16 org.drools.compiler.rule.builder.MVELConstraintBuilder$StringCoercionCompatibilityEvaluator 1246: 1 16 org.drools.compiler.rule.builder.RuleBuilder 1247: 1 16 org.drools.compiler.rule.builder.dialect.asm.ASMConsequenceStubBuilder 1248: 1 16 org.drools.compiler.rule.builder.dialect.asm.ASMEvalStubBuilder 1249: 1 16 org.drools.compiler.rule.builder.dialect.asm.ASMPredicateStubBuilder 1250: 1 16 org.drools.compiler.rule.builder.dialect.asm.ASMReturnValueStubBuilder 1251: 1 16 org.drools.compiler.rule.builder.dialect.java.JavaAccumulateBuilder 1252: 1 16 org.drools.compiler.rule.builder.dialect.java.JavaExprAnalyzer 1253: 1 16 org.drools.compiler.rule.builder.dialect.java.JavaRuleClassBuilder 1254: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$1 1255: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$10 1256: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$11 1257: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$2 1258: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$3 1259: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$4 1260: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$5 1261: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$6 1262: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$7 1263: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$8 1264: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$9 1265: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELAccumulateBuilder 1266: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder 1267: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$1 1268: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$10 1269: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$11 1270: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$2 1271: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$3 1272: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$4 1273: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$5 1274: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$6 1275: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$7 1276: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$8 1277: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$9 1278: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELEvalBuilder 1279: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELExprAnalyzer 1280: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELPredicateBuilder 1281: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELReturnValueBuilder 1282: 1 16 org.drools.core.RuleActivationListenerFactory 1283: 1 16 org.drools.core.base.CalendarsImpl 1284: 1 16 org.drools.core.base.ClassFieldAccessorFactory 1285: 1 16 org.drools.core.base.FieldFactory 1286: 1 16 org.drools.core.base.SalienceInteger 1287: 1 16 org.drools.core.base.TypeResolver$AcceptAllClassFilter 1288: 1 16 org.drools.core.base.TypeResolver$ExcludeAnnotationClassFilter 1289: 1 16 org.drools.core.base.TypeResolver$OnlyAnnotationClassFilter 1290: 1 16 org.drools.core.base.accumulators.CollectAccumulator$CollectContext 1291: 1 16 org.drools.core.base.evaluators.IsAEvaluatorDefinition 1292: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BooleanArrayContainsEvaluator 1293: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ByteArrayContainsEvaluator 1294: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$CharArrayContainsEvaluator 1295: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$DoubleArrayContainsEvaluator 1296: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$FloatArrayContainsEvaluator 1297: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$IntegerArrayContainsEvaluator 1298: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$LongArrayContainsEvaluator 1299: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ObjectArrayContainsEvaluator 1300: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ShortArrayContainsEvaluator 1301: 1 16 org.drools.core.base.evaluators.StrEvaluatorDefinition 1302: 1 16 org.drools.core.base.mvel.MVELCalendarCoercion 1303: 1 16 org.drools.core.base.mvel.MVELCompilationUnit$InterceptorMap 1304: 1 16 org.drools.core.base.mvel.MVELDateCoercion 1305: 1 16 org.drools.core.base.mvel.MVELDebugHandler$MVELDebugger 1306: 1 16 org.drools.core.common.EmptyBetaConstraints 1307: 1 16 org.drools.core.common.IdentityAssertMapComparator 1308: 1 16 org.drools.core.common.PriorityQueueAgendaGroupFactory 1309: 1 16 org.drools.core.concurrent.ExecutorProviderImpl 1310: 1 16 org.drools.core.concurrent.ExecutorProviderImpl$DaemonThreadFactory 1311: 1 16 org.drools.core.conflict.DepthConflictResolver 1312: 1 16 org.drools.core.event.AgendaEventSupport 1313: 1 16 org.drools.core.event.RuleEventListenerSupport 1314: 1 16 org.drools.core.event.RuleRuntimeEventSupport 1315: 1 16 org.drools.core.impl.KnowledgeBaseFactoryServiceImpl 1316: 1 16 org.drools.core.io.impl.ResourceFactoryServiceImpl 1317: 1 16 org.drools.core.marshalling.impl.ClassObjectMarshallingStrategyAcceptor 1318: 1 16 org.drools.core.phreak.PhreakAccumulateNode 1319: 1 16 org.drools.core.phreak.PhreakBranchNode 1320: 1 16 org.drools.core.phreak.PhreakEvalNode 1321: 1 16 org.drools.core.phreak.PhreakExistsNode 1322: 1 16 org.drools.core.phreak.PhreakFromNode 1323: 1 16 org.drools.core.phreak.PhreakJoinNode 1324: 1 16 org.drools.core.phreak.PhreakNotNode 1325: 1 16 org.drools.core.phreak.PhreakQueryNode 1326: 1 16 org.drools.core.phreak.PhreakQueryTerminalNode 1327: 1 16 org.drools.core.phreak.PhreakRuleTerminalNode 1328: 1 16 org.drools.core.phreak.PhreakTimerNode 1329: 1 16 org.drools.core.phreak.RuleExecutor$SalienceComparator 1330: 1 16 org.drools.core.phreak.RuleNetworkEvaluator 1331: 1 16 org.drools.core.reteoo.ClassObjectTypeConf$ObjectTypeNodeComparator 1332: 1 16 org.drools.core.reteoo.EmptyLeftTupleSinkAdapter 1333: 1 16 org.drools.core.reteoo.EmptyObjectSinkAdapter 1334: 1 16 org.drools.core.reteoo.InitialFactImpl 1335: 1 16 org.drools.core.reteoo.ObjectTypeNode$ExpireJob 1336: 1 16 org.drools.core.reteoo.RuleTerminalNode$SortDeclarations 1337: 1 16 org.drools.core.reteoo.SegmentMemory$AccumulateMemoryPrototype 1338: 1 16 org.drools.core.reteoo.builder.BuildUtils 1339: 1 16 org.drools.core.reteoo.builder.CollectBuilder 1340: 1 16 org.drools.core.reteoo.builder.ConditionalBranchBuilder 1341: 1 16 org.drools.core.reteoo.builder.EntryPointBuilder 1342: 1 16 org.drools.core.reteoo.builder.EvalBuilder 1343: 1 16 org.drools.core.reteoo.builder.ForallBuilder 1344: 1 16 org.drools.core.reteoo.builder.FromBuilder 1345: 1 16 org.drools.core.reteoo.builder.GroupElementBuilder 1346: 1 16 org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder 1347: 1 16 org.drools.core.reteoo.builder.GroupElementBuilder$ExistsBuilder 1348: 1 16 org.drools.core.reteoo.builder.GroupElementBuilder$NotBuilder 1349: 1 16 org.drools.core.reteoo.builder.GroupElementBuilder$OrBuilder 1350: 1 16 org.drools.core.reteoo.builder.NamedConsequenceBuilder 1351: 1 16 org.drools.core.reteoo.builder.PatternBuilder 1352: 1 16 org.drools.core.reteoo.builder.QueryElementBuilder 1353: 1 16 org.drools.core.reteoo.builder.ReteooRuleBuilder 1354: 1 16 org.drools.core.reteoo.builder.TimerBuilder 1355: 1 16 org.drools.core.reteoo.builder.WindowReferenceBuilder 1356: 1 16 org.drools.core.rule.EntryPointId 1357: 1 16 org.drools.core.rule.LogicTransformer 1358: 1 16 org.drools.core.rule.LogicTransformer$AndOrTransformation 1359: 1 16 org.drools.core.rule.LogicTransformer$ExistOrTransformation 1360: 1 16 org.drools.core.rule.LogicTransformer$NotOrTransformation 1361: 1 16 org.drools.core.rule.constraint.MvelConstraint$PlainIndexEvaluator 1362: 1 16 org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler 1363: 1 16 org.drools.core.time.impl.DefaultTimerJobFactoryManager 1364: 1 16 org.drools.core.type.DateFormatsImpl$1 1365: 1 16 org.drools.core.type.DateFormatsImpl$2 1366: 1 16 org.drools.core.util.AbstractHashTable$EqualityEquals 1367: 1 16 org.drools.core.util.LinkedList$LinkedListFastIterator 1368: 1 16 org.drools.core.util.MVELSafeHelper$RawMVELEvaluator 1369: 1 16 org.drools.core.util.MemoryUtil$MemoryStats 1370: 1 16 org.drools.core.util.Predicate$PassAll 1371: 1 16 org.drools.core.util.bitmask.AllSetBitMask 1372: 1 16 org.drools.core.util.bitmask.AllSetButLastBitMask 1373: 1 16 org.drools.core.util.bitmask.EmptyBitMask 1374: 1 16 org.eclipse.jdt.internal.compiler.CompilationResult$1 1375: 1 16 org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration$1 1376: 1 16 org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$2 1377: 1 16 org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$3 1378: 1 16 org.kie.api.runtime.conf.BeliefSystemTypeOption 1379: 1 16 org.kie.api.runtime.conf.ClockTypeOption 1380: 1 16 org.kie.api.runtime.conf.TimedRuleExectionOption$1 1381: 1 16 org.kie.internal.assembler.KieAssemblersImpl 1382: 1 16 org.kie.internal.conf.ConsequenceExceptionHandlerOption 1383: 1 16 org.kie.internal.runtime.KieRuntimesImpl 1384: 1 16 org.kie.internal.runtime.conf.ForceEagerActivationOption$1 1385: 1 16 org.kie.internal.runtime.conf.ForceEagerActivationOption$2 1386: 1 16 org.kie.internal.weaver.KieWeaversImpl 1387: 1 16 org.mvel2.compiler.BlankLiteral 1388: 1 16 org.mvel2.conversion.BigDecimalCH 1389: 1 16 org.mvel2.conversion.BigDecimalCH$1 1390: 1 16 org.mvel2.conversion.BigDecimalCH$10 1391: 1 16 org.mvel2.conversion.BigDecimalCH$11 1392: 1 16 org.mvel2.conversion.BigDecimalCH$2 1393: 1 16 org.mvel2.conversion.BigDecimalCH$3 1394: 1 16 org.mvel2.conversion.BigDecimalCH$5 1395: 1 16 org.mvel2.conversion.BigDecimalCH$6 1396: 1 16 org.mvel2.conversion.BigDecimalCH$7 1397: 1 16 org.mvel2.conversion.BigDecimalCH$8 1398: 1 16 org.mvel2.conversion.BigDecimalCH$9 1399: 1 16 org.mvel2.conversion.BigIntegerCH 1400: 1 16 org.mvel2.conversion.BigIntegerCH$1 1401: 1 16 org.mvel2.conversion.BigIntegerCH$2 1402: 1 16 org.mvel2.conversion.BigIntegerCH$3 1403: 1 16 org.mvel2.conversion.BigIntegerCH$5 1404: 1 16 org.mvel2.conversion.BigIntegerCH$6 1405: 1 16 org.mvel2.conversion.BigIntegerCH$7 1406: 1 16 org.mvel2.conversion.BigIntegerCH$8 1407: 1 16 org.mvel2.conversion.BigIntegerCH$9 1408: 1 16 org.mvel2.conversion.BooleanCH$1 1409: 1 16 org.mvel2.conversion.BooleanCH$10 1410: 1 16 org.mvel2.conversion.BooleanCH$2 1411: 1 16 org.mvel2.conversion.BooleanCH$3 1412: 1 16 org.mvel2.conversion.BooleanCH$4 1413: 1 16 org.mvel2.conversion.BooleanCH$5 1414: 1 16 org.mvel2.conversion.BooleanCH$6 1415: 1 16 org.mvel2.conversion.BooleanCH$7 1416: 1 16 org.mvel2.conversion.BooleanCH$8 1417: 1 16 org.mvel2.conversion.BooleanCH$9 1418: 1 16 org.mvel2.conversion.ByteCH 1419: 1 16 org.mvel2.conversion.ByteCH$1 1420: 1 16 org.mvel2.conversion.ByteCH$2 1421: 1 16 org.mvel2.conversion.ByteCH$3 1422: 1 16 org.mvel2.conversion.ByteCH$4 1423: 1 16 org.mvel2.conversion.ByteCH$5 1424: 1 16 org.mvel2.conversion.ByteCH$6 1425: 1 16 org.mvel2.conversion.ByteCH$7 1426: 1 16 org.mvel2.conversion.ByteCH$8 1427: 1 16 org.mvel2.conversion.CharArrayCH 1428: 1 16 org.mvel2.conversion.CharArrayCH$1 1429: 1 16 org.mvel2.conversion.CharCH 1430: 1 16 org.mvel2.conversion.CharCH$1 1431: 1 16 org.mvel2.conversion.CharCH$2 1432: 1 16 org.mvel2.conversion.CharCH$3 1433: 1 16 org.mvel2.conversion.CharCH$4 1434: 1 16 org.mvel2.conversion.CharCH$5 1435: 1 16 org.mvel2.conversion.CompositeCH 1436: 1 16 org.mvel2.conversion.DoubleCH 1437: 1 16 org.mvel2.conversion.DoubleCH$1 1438: 1 16 org.mvel2.conversion.DoubleCH$10 1439: 1 16 org.mvel2.conversion.DoubleCH$2 1440: 1 16 org.mvel2.conversion.DoubleCH$3 1441: 1 16 org.mvel2.conversion.DoubleCH$4 1442: 1 16 org.mvel2.conversion.DoubleCH$5 1443: 1 16 org.mvel2.conversion.DoubleCH$6 1444: 1 16 org.mvel2.conversion.DoubleCH$7 1445: 1 16 org.mvel2.conversion.DoubleCH$8 1446: 1 16 org.mvel2.conversion.DoubleCH$9 1447: 1 16 org.mvel2.conversion.FloatCH 1448: 1 16 org.mvel2.conversion.FloatCH$1 1449: 1 16 org.mvel2.conversion.FloatCH$10 1450: 1 16 org.mvel2.conversion.FloatCH$2 1451: 1 16 org.mvel2.conversion.FloatCH$3 1452: 1 16 org.mvel2.conversion.FloatCH$4 1453: 1 16 org.mvel2.conversion.FloatCH$5 1454: 1 16 org.mvel2.conversion.FloatCH$6 1455: 1 16 org.mvel2.conversion.FloatCH$7 1456: 1 16 org.mvel2.conversion.FloatCH$8 1457: 1 16 org.mvel2.conversion.FloatCH$9 1458: 1 16 org.mvel2.conversion.IntArrayCH 1459: 1 16 org.mvel2.conversion.IntArrayCH$1 1460: 1 16 org.mvel2.conversion.IntArrayCH$2 1461: 1 16 org.mvel2.conversion.IntegerCH 1462: 1 16 org.mvel2.conversion.IntegerCH$1 1463: 1 16 org.mvel2.conversion.IntegerCH$10 1464: 1 16 org.mvel2.conversion.IntegerCH$11 1465: 1 16 org.mvel2.conversion.IntegerCH$2 1466: 1 16 org.mvel2.conversion.IntegerCH$3 1467: 1 16 org.mvel2.conversion.IntegerCH$4 1468: 1 16 org.mvel2.conversion.IntegerCH$5 1469: 1 16 org.mvel2.conversion.IntegerCH$6 1470: 1 16 org.mvel2.conversion.IntegerCH$7 1471: 1 16 org.mvel2.conversion.IntegerCH$8 1472: 1 16 org.mvel2.conversion.IntegerCH$9 1473: 1 16 org.mvel2.conversion.ListCH 1474: 1 16 org.mvel2.conversion.LongCH 1475: 1 16 org.mvel2.conversion.LongCH$1 1476: 1 16 org.mvel2.conversion.LongCH$10 1477: 1 16 org.mvel2.conversion.LongCH$2 1478: 1 16 org.mvel2.conversion.LongCH$3 1479: 1 16 org.mvel2.conversion.LongCH$4 1480: 1 16 org.mvel2.conversion.LongCH$5 1481: 1 16 org.mvel2.conversion.LongCH$6 1482: 1 16 org.mvel2.conversion.LongCH$7 1483: 1 16 org.mvel2.conversion.LongCH$8 1484: 1 16 org.mvel2.conversion.LongCH$9 1485: 1 16 org.mvel2.conversion.ObjectCH 1486: 1 16 org.mvel2.conversion.SetCH 1487: 1 16 org.mvel2.conversion.ShortCH 1488: 1 16 org.mvel2.conversion.ShortCH$1 1489: 1 16 org.mvel2.conversion.ShortCH$10 1490: 1 16 org.mvel2.conversion.ShortCH$2 1491: 1 16 org.mvel2.conversion.ShortCH$3 1492: 1 16 org.mvel2.conversion.ShortCH$4 1493: 1 16 org.mvel2.conversion.ShortCH$5 1494: 1 16 org.mvel2.conversion.ShortCH$6 1495: 1 16 org.mvel2.conversion.ShortCH$7 1496: 1 16 org.mvel2.conversion.ShortCH$8 1497: 1 16 org.mvel2.conversion.ShortCH$9 1498: 1 16 org.mvel2.conversion.StringArrayCH 1499: 1 16 org.mvel2.conversion.StringArrayCH$1 1500: 1 16 org.mvel2.conversion.StringCH 1501: 1 16 org.slf4j.helpers.NOPLogger 1502: 1 16 org.slf4j.helpers.NOPLoggerFactory 1503: 1 16 org.slf4j.helpers.SubstituteLoggerFactory 1504: 1 16 sun.jvmstat.monitor.HostIdentifier 1505: 1 16 sun.jvmstat.perfdata.monitor.protocol.local.LocalVmManager$1 1506: 1 16 sun.jvmstat.perfdata.monitor.protocol.local.LocalVmManager$2 1507: 1 16 sun.jvmstat.perfdata.monitor.protocol.local.LocalVmManager$3 1508: 1 16 sun.misc.ASCIICaseInsensitiveComparator 1509: 1 16 sun.misc.FloatingDecimal$1 1510: 1 16 sun.misc.Launcher 1511: 1 16 sun.misc.Launcher$Factory 1512: 1 16 sun.misc.Perf 1513: 1 16 sun.misc.Unsafe 1514: 1 16 sun.net.DefaultProgressMeteringPolicy 1515: 1 16 sun.net.www.protocol.file.Handler 1516: 1 16 sun.net.www.protocol.jar.JarFileFactory 1517: 1 16 sun.reflect.GeneratedConstructorAccessor1 1518: 1 16 sun.reflect.GeneratedConstructorAccessor2 1519: 1 16 sun.reflect.GeneratedConstructorAccessor3 1520: 1 16 sun.reflect.GeneratedMethodAccessor1 1521: 1 16 sun.reflect.GeneratedMethodAccessor2 1522: 1 16 sun.reflect.GeneratedMethodAccessor3 1523: 1 16 sun.reflect.GeneratedMethodAccessor4 1524: 1 16 sun.reflect.GeneratedMethodAccessor5 1525: 1 16 sun.reflect.GeneratedMethodAccessor6 1526: 1 16 sun.reflect.ReflectionFactory 1527: 1 16 sun.security.provider.NativePRNG 1528: 1 16 sun.tools.attach.LinuxAttachProvider 1529: 1 16 sun.util.calendar.Gregorian 1530: 1 16 sun.util.calendar.JulianCalendar 1531: 1 16 sun.util.locale.InternalLocaleBuilder$CaseInsensitiveChar 1532: 1 16 sun.util.locale.provider.AuxLocaleProviderAdapter$NullProvider 1533: 1 16 sun.util.locale.provider.CalendarDataUtility$CalendarWeekParameterGetter 1534: 1 16 sun.util.locale.provider.SPILocaleProviderAdapter 1535: 1 16 sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter 1536: 1 16 sun.util.resources.LocaleData 1537: 1 16 sun.util.resources.LocaleData$LocaleDataResourceBundleControl Total 82225 12605296 > memory leak > ----------- > > Key: DROOLS-647 > URL: https://issues.jboss.org/browse/DROOLS-647 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Reporter: Dawna Floyd > Assignee: Mario Fusco > Fix For: 6.2.0.CR3 > > Attachments: DROOL_TEST.zip > > > references to fact handles not being removed when objects are removed from memory. Converted our application from 5.0.1 to 6.1_Final and encountered memory leaks in the drools processing. Found references to defect 498 and checked out the 6.1.1 code based and built the source (the download package doesn't seem to have these fixes). The majority of leaks were corrected with this code line, however there still remains a memory leak when we run our defined rules. Even though a rule never fires, it's evaluation seems to hold onto beta memory forever and the test application will eventually run out of memory. I can provide a test program that highlights the leak. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:39:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 18 Nov 2014 08:39:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Duplicate method call inside patterns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco updated DROOLS-651: ------------------------------- Assignee: Michael Anstis (was: Mark Proctor) > Duplicate method call inside patterns > ------------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Michael Anstis > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:41:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 18 Nov 2014 08:41:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Duplicate method call inside patterns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-651: ---------------------------------- Assignee: Mario Fusco (was: Michael Anstis) > Duplicate method call inside patterns > ------------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mario Fusco > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:42:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 18 Nov 2014 08:42:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-649) Complex Dependencies Cause In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco updated DROOLS-649: ------------------------------- Assignee: Michael Anstis (was: Mark Proctor) > Complex Dependencies Cause > --------------------------- > > Key: DROOLS-649 > URL: https://issues.jboss.org/browse/DROOLS-649 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Environment: Drools 6.1.0, WildFly 8.1, JDK 1.7 > Reporter: Patrick Thomas > Assignee: Michael Anstis > Labels: dependency, kie > > When I add a dependency to my project that has other dependencies, KIE fills up my log file with multiple warnings and errors. See the forum reference for a sampling of messages I am receiving. One single reference filled my log file with 8MB of messages. > KIE appears to attempt to load every dependency of my dependency, and every dependency of those dependencies, and so on. The system becomes unusable for a while. After the scan is done, my Type drop down in the Data Modeler is filled with so many classes that it is difficult to find what I need. > The last problem (not mentioned in the forum) is that I can't shut down WildFly. I seem to get stuck in an endless loop with the following message being displayed repeatedly: > 13:41:55,522 WARN [org.jbpm.executor.impl.ExecutorRunnable] (pool-14-thread-1) Error while executing jobs due to {}null > It's possible that WildFly would eventually shut down, but I end up stopping the task forcibly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:51:40 2014 From: issues at jboss.org (Dawna Floyd (JIRA)) Date: Tue, 18 Nov 2014 08:51:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-647) memory leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020795#comment-13020795 ] Dawna Floyd commented on DROOLS-647: ------------------------------------ The defect was raised against 6.1 (or I thought it was)? we are running againt 6.1.1. (since 6.1 is the latest Released version.. the 6.1 downlad package is missing other memory fixes that are in 6.1.1? so we had to build it in order to get those fixes). It looks like you ran against 6.2? But, 6.1 is the latest released version. Is there a plan to fix the issue in 6.1 , and to fix the release package for 6.1 so that it contains the fixes for the other memory leaks? Are you saying we have to use the un-released 6.2 version if we want the memory fixes? Are you saying it?s been fixed in 6.1 and we just need to pull a newer version and build it? Or am I just completely misunderstanding your response? Thanks Dawna From: Mario Fusco (JIRA) [mailto:issues at jboss.org] Sent: Tuesday, November 18, 2014 7:09 AM To: Floyd, Dawna Subject: [JBoss JIRA] (DROOLS-647) memory leak [https://developer.jboss.org/gravatar/9eafc29df96e6aaf4a3eb4c0209086ae?d=mm&s=48] Mario Fusco resolved as Cannot Reproduce Bug I ran your test case against the master branch, but couldn't reproduce any leak. In particular I printed the whole JVM heap after its execution and I am pasting it below. As you can see, after the 10,000 loops of your test there is only one instance for each com.sample.OprOBActionGroupSOsIntoIOPs, com.sample.OprOBProductCodeProductType, com.sample.OprOBServiceOrder and com.sample.ServiceOrder and 2 of com.sample.OprOBBusAct and com.sample.BusinessActivity and this happens simply because the last loop doesn't trigger a fireAllRules after having deleted them from the ksession. I believe this leak has been already fixed by a former commit. num #instances #bytes class name ---------------------------------------------- 1: 1930 8446120 [S 2: 17305 1367520 [C 3: 4222 453592 java.lang.Class 4: 16545 397080 java.lang.String 5: 547 260192 [B 6: 5843 186976 java.util.concurrent.ConcurrentHashMap$Node 7: 2095 146968 [Ljava.lang.Object; 8: 4573 146336 java.util.HashMap$Node 9: 1174 103312 java.lang.reflect.Method 10: 1814 92464 [I 11: 5494 87904 java.lang.Object 12: 502 87368 [Ljava.util.HashMap$Node; 13: 2036 81440 java.util.LinkedHashMap$Entry 14: 1268 61184 [Ljava.lang.String; 15: 572 41184 java.lang.reflect.Field 16: 1174 39240 [J 17: 54 39040 [Ljava.util.concurrent.ConcurrentHashMap$Node; 18: 674 32352 java.util.HashMap 19: 1211 26128 [Ljava.lang.Class; 20: 304 24320 java.lang.reflect.Constructor 21: 105 21000 com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDecl 22: 1165 18640 org.antlr.runtime.BitSet 23: 582 18624 java.util.Hashtable$Entry 24: 225 12600 java.lang.Class$ReflectionData 25: 173 12456 org.mvel2.ast.ASTNode 26: 341 10912 sun.misc.FDBigInteger 27: 214 10272 org.mvel2.templates.res.TextNode 28: 242 9680 java.lang.ref.SoftReference 29: 29 9488 [Lorg.drools.core.util.Entry; 30: 166 9296 java.lang.Package 31: 62 9112 [Lcom.sun.org.apache.xerces.internal.util.SymbolHash$Entry; 32: 25 7704 [[S 33: 60 7088 [Ljava.util.Hashtable$Entry; 34: 291 6984 java.util.jar.Attributes$Name 35: 109 6976 java.net.URL 36: 418 6688 java.lang.Integer 37: 68 6376 [Ljava.lang.reflect.Method; 38: 243 5832 com.sun.org.apache.xerces.internal.util.SymbolHash$Entry 39: 142 5680 java.lang.ref.Finalizer 40: 160 5120 org.mvel2.compiler.ExecutableAccessor 41: 60 4816 [Ljava.util.WeakHashMap$Entry; 42: 187 4488 java.util.ArrayList 43: 69 4416 java.util.concurrent.ConcurrentHashMap 44: 86 4128 org.mvel2.templates.res.CompiledExpressionNode 45: 256 4096 java.lang.Short 46: 91 3640 java.math.BigInteger 47: 88 3608 [Ljava.lang.reflect.Field; 48: 146 3520 [Ljava.lang.reflect.Constructor; 49: 62 3472 java.util.zip.ZipFile$ZipFileInputStream 50: 47 3384 org.mvel2.ast.OperatorNode 51: 140 3360 sun.reflect.NativeConstructorAccessorImpl 52: 36 3168 org.mvel2.ast.BinaryOperation 53: 63 3024 org.mvel2.templates.res.TerminalNode 54: 8 3008 java.lang.Thread 55: 60 2880 java.util.WeakHashMap 56: 23 2848 [Z 57: 27 2808 org.mvel2.ParserContext 58: 39 2808 org.mvel2.ast.LiteralNode 59: 82 2776 [[C 60: 27 2592 org.mvel2.compiler.ExpressionCompiler 61: 64 2560 java.util.TreeMap$Entry 62: 3 2520 [[Ljava.lang.String; 63: 51 2448 sun.util.locale.LocaleObjectCache$CacheEntry 64: 76 2432 java.util.Vector 65: 25 2400 sun.util.calendar.Gregorian$Date 66: 33 2376 org.mvel2.templates.res.CompiledForEachNode 67: 49 2352 sun.misc.URLClassPath$JarLoader 68: 42 2352 sun.nio.cs.UTF_8$Encoder 69: 143 2288 sun.reflect.DelegatingConstructorAccessorImpl 70: 69 2208 java.lang.ref.ReferenceQueue 71: 38 2128 java.util.LinkedHashMap 72: 85 2040 org.mvel2.util.ExecutionStack 73: 31 1984 java.util.jar.JarFile 74: 20 1920 java.util.jar.JarFile$JarFileEntry 75: 39 1872 java.util.Hashtable 76: 1 1712 [[B 77: 30 1680 java.security.Provider$Service 78: 69 1656 java.security.Provider$ServiceKey 79: 41 1640 java.io.ObjectStreamField 80: 84 1632 [Lorg.drools.core.rule.Declaration; 81: 51 1632 org.drools.core.base.AccessorKey 82: 40 1600 java.security.ProtectionDomain 83: 25 1600 org.drools.core.base.mvel.MVELCompilationUnit 84: 33 1584 com.sun.org.apache.xerces.internal.impl.dv.xs.DecimalDV$XDecimal 85: 22 1584 org.drools.core.rule.constraint.MvelConstraint 86: 97 1552 java.util.HashSet 87: 48 1536 com.sun.org.apache.xerces.internal.impl.xs.traversers.OneAttr 88: 63 1512 com.thoughtworks.xstream.core.util.PrioritizedList$PrioritizedItem 89: 62 1488 com.sun.org.apache.xerces.internal.util.SymbolHash 90: 46 1472 com.sun.org.apache.xerces.internal.util.SymbolTable$Entry 91: 16 1408 org.drools.compiler.lang.descr.PatternDescr 92: 25 1400 org.drools.compiler.lang.descr.ExprConstraintDescr 93: 1 1376 [Lsun.misc.FDBigInteger; 94: 23 1288 org.mvel2.templates.res.CompiledIfNode 95: 40 1280 java.security.CodeSource 96: 32 1280 java.util.WeakHashMap$Entry 97: 41 1264 [Lcom.sun.org.apache.xerces.internal.impl.xs.traversers.OneAttr; 98: 2 1264 com.sample.BusinessActivity 99: 26 1248 com.sun.org.apache.xerces.internal.impl.xs.XSAttributeDecl 100: 38 1216 java.util.zip.ZipCoder 101: 50 1200 org.drools.core.base.evaluators.Operator 102: 38 1184 [Ljava.math.BigInteger; 103: 36 1152 sun.reflect.UnsafeStaticObjectFieldAccessorImpl 104: 71 1136 java.lang.ref.ReferenceQueue$Lock 105: 19 1064 org.drools.compiler.lang.descr.AndDescr 106: 19 1064 org.drools.core.rule.Pattern 107: 22 1056 java.util.zip.Inflater 108: 1 1040 [Ljava.lang.Integer; 109: 1 1040 [Ljava.lang.Short; 110: 26 1040 org.drools.core.rule.Declaration 111: 10 1040 org.drools.core.rule.TypeDeclaration 112: 26 1040 org.mvel2.ParserConfiguration 113: 18 1008 java.util.ResourceBundle$CacheKey 114: 25 1000 sun.util.locale.BaseLocale$Key 115: 30 960 java.security.Provider$EngineDescription 116: 24 960 java.util.IdentityHashMap 117: 13 936 com.sun.org.apache.xerces.internal.impl.xs.XSElementDecl 118: 38 912 java.util.ArrayDeque 119: 19 912 java.util.Properties 120: 36 864 com.sun.org.apache.xerces.internal.impl.xs.traversers.SmallContainer 121: 36 864 java.util.Date 122: 18 864 java.util.ResourceBundle$BundleReference 123: 12 864 java.util.regex.Pattern 124: 12 864 org.drools.core.common.PhreakPropagationContext 125: 26 832 com.sun.org.apache.xerces.internal.impl.xs.XSAttributeUseImpl 126: 13 832 com.sun.org.apache.xerces.internal.impl.xs.XSComplexTypeDecl 127: 25 800 java.util.Locale 128: 25 800 sun.util.locale.BaseLocale 129: 33 792 [Ljava.io.Serializable; 130: 9 792 org.drools.core.reteoo.RightTuple 131: 33 792 org.mvel2.compiler.ExecutableLiteral 132: 49 784 java.util.jar.Attributes 133: 7 784 org.drools.core.reteoo.JoinNode 134: 19 760 com.sun.org.apache.xerces.internal.impl.xs.XSParticleDecl 135: 9 720 org.drools.core.common.DefaultFactHandle 136: 9 720 org.mvel2.ast.And 137: 1 712 [Lcom.sun.org.apache.xerces.internal.util.SymbolTable$Entry; 138: 11 704 org.drools.core.reteoo.BetaMemory 139: 29 696 org.drools.core.base.ValueType 140: 21 672 java.io.File 141: 28 672 java.security.Provider$UString 142: 7 672 org.drools.core.reteoo.JoinNodeLeftTuple 143: 21 672 org.kie.api.io.ResourceType 144: 9 648 org.drools.core.reteoo.ObjectTypeNode 145: 9 648 sun.reflect.DelegatingClassLoader 146: 40 640 [Ljava.security.Principal; 147: 40 640 java.security.ProtectionDomain$Key 148: 20 640 org.drools.core.base.ClassObjectType 149: 4 624 [D 150: 13 624 com.sun.org.apache.xerces.internal.impl.xs.XSAttributeGroupDecl 151: 39 624 java.util.regex.Pattern$CharPropertyNames$1 152: 39 624 org.drools.core.base.evaluators.TimeIntervalParser 153: 11 616 sun.util.calendar.ZoneInfo 154: 25 600 java.util.Locale$LocaleKey 155: 36 576 java.util.HashMap$KeySet 156: 18 576 java.util.ResourceBundle$LoaderReference 157: 6 576 org.drools.core.common.ProjectClassLoader 158: 35 560 java.util.concurrent.atomic.AtomicInteger 159: 7 560 sun.net.www.protocol.jar.URLJarFile 160: 23 552 com.sun.org.apache.xerces.internal.impl.xs.util.XSObjectListImpl 161: 22 528 com.thoughtworks.xstream.io.xml.XmlFriendlyNameCoder$IntPair 162: 33 528 java.util.concurrent.atomic.AtomicBoolean 163: 22 528 java.util.zip.ZStreamRef 164: 11 528 org.drools.core.common.SynchronizedRightTupleSets 165: 22 528 org.mvel2.optimizers.impl.refl.nodes.VariableAccessor 166: 13 520 org.drools.core.rule.constraint.ConditionAnalyzer$AritmeticOperator 167: 8 512 java.nio.DirectByteBuffer 168: 16 512 java.util.Collections$SynchronizedMap 169: 8 512 org.drools.core.reteoo.AlphaNode 170: 7 480 [[I 171: 3 480 com.sun.org.apache.xerces.internal.impl.xs.SchemaGrammar$BuiltinSchemaGrammar 172: 6 480 com.sun.org.apache.xerces.internal.impl.xs.models.XSDFACM 173: 12 480 java.security.AccessControlContext 174: 15 480 java.util.regex.Pattern$Curly 175: 10 480 org.drools.core.util.asm.ClassFieldInspector 176: 16 456 [Ljava.io.ObjectStreamField; 177: 28 448 java.util.HashMap$EntrySet 178: 14 448 java.util.concurrent.locks.ReentrantLock$NonfairSync 179: 7 448 org.drools.compiler.lang.descr.AttributeDescr 180: 8 448 org.drools.core.util.index.LeftTupleIndexHashTable 181: 8 448 org.drools.core.util.index.RightTupleIndexHashTable 182: 27 432 com.thoughtworks.xstream.converters.SingleValueConverterWrapper 183: 18 432 java.text.DateFormat$Field 184: 9 432 org.drools.core.reteoo.ClassObjectTypeConf 185: 9 432 org.drools.core.util.index.RightTupleList 186: 13 424 [Lcom.sun.org.apache.xerces.internal.impl.xs.XSAttributeUseImpl; 187: 4 416 com.sun.org.apache.xerces.internal.impl.dv.xs.AbstractDateTimeDV$DateTimeData 188: 13 416 java.io.FileDescriptor 189: 26 416 java.util.HashMap$Values 190: 13 416 org.drools.core.rule.constraint.MvelConstraint$MvelContextEntry 191: 26 416 org.eclipse.jdt.internal.compiler.impl.IrritantSet 192: 17 408 java.lang.Class$AnnotationData 193: 17 408 org.drools.compiler.rule.builder.dialect.java.parser.JavaBlockDescr$BlockType 194: 25 400 [Lorg.drools.core.base.EvaluatorWrapper; 195: 10 400 com.sun.org.apache.xerces.internal.impl.xpath.regex.RangeToken 196: 10 400 org.drools.core.util.index.LeftTupleList 197: 7 392 org.mvel2.templates.res.CompiledDeclareNode 198: 12 384 java.io.FilePermission 199: 1 384 java.lang.ref.Finalizer$FinalizerThread 200: 12 384 java.security.BasicPermissionCollection 201: 12 384 java.security.Permissions 202: 16 384 org.drools.compiler.lang.DroolsParaphraseTypes 203: 4 384 org.drools.core.definitions.impl.KnowledgePackageImpl 204: 4 384 org.drools.core.reteoo.SegmentMemory 205: 8 384 org.mvel2.templates.res.EndNode 206: 1 376 java.lang.ref.Reference$ReferenceHandler 207: 23 368 java.awt.font.TextAttribute 208: 15 360 java.lang.RuntimePermission 209: 15 360 org.drools.core.base.ClassFieldAccessorCache$ClassObjectTypeKey 210: 15 360 org.drools.core.base.ClassFieldAccessorStore$FieldLookupEntry 211: 15 360 org.drools.core.base.ClassFieldReader 212: 3 360 org.drools.core.definitions.rule.impl.RuleImpl 213: 9 360 org.drools.core.util.ObjectHashSet 214: 5 360 org.mvel2.ast.Substatement 215: 15 360 sun.misc.MetaIndex 216: 22 352 java.lang.Float 217: 11 352 org.drools.core.rule.GroupElement 218: 8 344 [Lcom.sun.org.apache.xerces.internal.impl.xs.util.SimpleLocator; 219: 6 336 java.nio.DirectLongBufferU 220: 14 336 org.drools.compiler.lang.DroolsSentenceType 221: 6 336 org.drools.core.factmodel.ClassDefinition 222: 3 336 org.drools.core.reteoo.NotNodeLeftTuple 223: 6 336 sun.management.MemoryPoolImpl 224: 7 336 sun.util.locale.provider.LocaleResources$ResourceReference 225: 8 320 com.thoughtworks.xstream.core.util.Pool 226: 4 320 org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader 227: 10 320 org.drools.core.spi.PatternExtractor 228: 10 320 org.drools.core.util.AbstractHashTable$SingleIndex 229: 10 320 org.eclipse.jdt.internal.compiler.lookup.BaseTypeBinding 230: 13 312 [Lcom.sun.org.apache.xerces.internal.impl.xs.identity.IdentityConstraint; 231: 13 312 java.util.concurrent.atomic.AtomicLong 232: 3 312 org.drools.compiler.lang.descr.RuleDescr 233: 13 312 org.drools.core.reteoo.ObjectTypeNode$Id 234: 2 304 org.drools.core.reteoo.RuleTerminalNodeLeftTuple 235: 8 288 [Ljava.lang.Boolean; 236: 4 288 [Lorg.drools.core.spi.Activation; 237: 12 288 com.sun.org.apache.xerces.internal.impl.xpath.regex.Token$CharToken 238: 12 288 java.io.FilePermissionCollection 239: 9 288 java.lang.OutOfMemoryError 240: 9 288 java.util.LinkedList 241: 12 288 java.util.jar.Manifest 242: 18 288 java.util.regex.Pattern$CharPropertyNames$4 243: 4 288 org.drools.core.base.ClassFieldAccessorCache$ByteArrayClassLoader 244: 12 288 org.drools.core.base.ClassFieldAccessorStore$ClassObjectTypeLookupEntry 245: 3 288 org.drools.core.phreak.RuleAgendaItem 246: 3 288 org.drools.core.reteoo.RuleTerminalNode 247: 12 288 org.drools.core.rule.constraint.ConditionAnalyzer$EvaluatedExpression 248: 9 288 org.mvel2.asm.Type 249: 9 288 sun.security.jca.ProviderConfig 250: 7 280 com.sun.org.apache.xerces.internal.utils.XMLSecurityManager$Limit 251: 5 272 [Lcom.sun.org.apache.xerces.internal.impl.xs.XSElementDecl; 252: 2 272 org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer 253: 17 272 sun.reflect.DelegatingMethodAccessorImpl 254: 11 264 org.drools.compiler.lang.DroolsEditorType 255: 11 264 org.drools.core.reteoo.SegmentMemory$BetaMemoryPrototype 256: 11 264 org.drools.core.reteoo.SingleLeftTupleSinkAdapter 257: 11 264 org.drools.core.util.AtomicBitwiseLong 258: 11 264 sun.jvmstat.perfdata.monitor.v2_0.TypeCode 259: 11 264 sun.reflect.NativeMethodAccessorImpl 260: 4 256 [Lcom.sun.org.apache.xerces.internal.impl.xs.XSComplexTypeDecl; 261: 8 256 java.io.FileInputStream 262: 8 256 java.lang.ThreadLocal$ThreadLocalMap$Entry 263: 4 256 org.drools.core.reteoo.SegmentMemory$Prototype 264: 16 256 org.eclipse.jdt.internal.compiler.impl.IntConstant 265: 10 240 [Lorg.drools.core.reteoo.LeftTupleSink; 266: 10 240 [Lorg.drools.core.rule.ContextEntry; 267: 10 240 java.util.LinkedList$Node 268: 3 240 org.drools.core.reteoo.KieComponentFactory 269: 2 240 org.drools.core.reteoo.NotNode 270: 10 240 org.drools.core.reteoo.SingleObjectSinkAdapter 271: 10 240 org.drools.core.rule.constraint.ConditionAnalyzer$BooleanOperator 272: 6 240 org.mvel2.compiler.CompiledExpression 273: 6 240 sun.management.MemoryPoolImpl$CollectionSensor 274: 6 240 sun.management.MemoryPoolImpl$PoolSensor 275: 4 224 com.sun.org.apache.xerces.internal.impl.xs.XSDDescription 276: 7 224 com.sun.org.apache.xerces.internal.impl.xs.XSModelGroupImpl 277: 2 224 java.net.SocksSocketImpl 278: 14 224 java.util.IdentityHashMap$KeySet 279: 14 224 java.util.LinkedHashMap$LinkedKeySet 280: 7 224 java.util.Stack 281: 14 224 java.util.concurrent.locks.ReentrantLock 282: 4 224 org.drools.core.rule.MVELDialectRuntimeData 283: 7 224 org.drools.core.rule.constraint.ConditionAnalyzer$SingleCondition 284: 9 216 java.util.regex.Pattern$Single 285: 9 216 org.drools.core.reteoo.ObjectTypeNode$IdGenerator 286: 9 216 org.drools.core.rule.constraint.MvelConstraint$1 287: 7 208 [Lcom.sun.org.apache.xerces.internal.xs.XSObject; 288: 2 208 org.drools.core.RuleBaseConfiguration 289: 13 208 org.kie.internal.utils.ServiceRegistryImpl$ReflectionInstantiator 290: 2 208 sun.util.calendar.ImmutableGregorianDate 291: 2 200 [Ljava.text.DateFormat$Field; 292: 5 200 java.lang.ClassLoader$NativeLibrary 293: 6 192 com.sun.org.apache.xerces.internal.impl.xpath.regex.Token$ClosureToken 294: 4 192 com.sun.org.apache.xerces.internal.impl.xs.SchemaGrammar$BuiltinAttrDecl 295: 8 192 com.thoughtworks.xstream.core.util.ThreadSafeSimpleDateFormat 296: 8 192 com.thoughtworks.xstream.core.util.ThreadSafeSimpleDateFormat$1 297: 8 192 java.math.RoundingMode 298: 4 192 java.util.concurrent.ConcurrentSkipListMap 299: 3 192 java.util.regex.Matcher 300: 8 192 java.util.regex.Pattern$5 301: 8 192 java.util.regex.Pattern$Start 302: 8 192 org.drools.core.reteoo.ObjectTypeNode$ObjectTypeNodeMemory 303: 8 192 org.drools.core.rule.constraint.ConditionAnalyzer$MethodInvocation 304: 8 192 org.drools.core.util.index.IndexUtil$ConstraintType 305: 2 192 org.eclipse.jdt.internal.compiler.CompilationResult 306: 8 192 org.mvel2.templates.CompiledTemplate 307: 3 192 sun.security.provider.NativePRNG$RandomIO 308: 7 184 [Lcom.sun.org.apache.xerces.internal.impl.xs.XSParticleDecl; 309: 11 176 com.sun.org.apache.xerces.internal.impl.xs.util.XInt 310: 1 176 org.mvel2.optimizers.impl.asm.ASMAccessorOptimizer 311: 7 168 [Lorg.drools.core.reteoo.ObjectTypeNode; 312: 1 168 [[Ljava.math.BigInteger; 313: 7 168 com.sun.org.apache.xerces.internal.util.FeatureState 314: 7 168 java.util.Collections$SynchronizedSet 315: 7 168 java.util.regex.Pattern$1 316: 7 168 java.util.regex.Pattern$BitClass 317: 7 168 java.util.regex.Pattern$GroupHead 318: 7 168 java.util.regex.Pattern$GroupTail 319: 3 168 org.drools.compiler.lang.descr.ExistsDescr 320: 3 168 org.drools.core.reteoo.PathMemory 321: 7 168 org.drools.core.util.AbstractHashTable$FieldIndex 322: 7 168 org.drools.core.util.LinkedList 323: 7 168 sun.jvmstat.monitor.Units 324: 7 168 sun.reflect.generics.tree.SimpleClassTypeSignature 325: 6 160 [Lcom.sun.org.apache.xerces.internal.xs.ShortList; 326: 2 160 [Ljava.lang.ThreadLocal$ThreadLocalMap$Entry; 327: 1 160 com.sun.org.apache.xerces.internal.impl.xs.SchemaGrammar 328: 2 160 org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl 329: 5 160 org.drools.compiler.lang.descr.ConnectiveType 330: 5 160 org.drools.core.factmodel.ClassBuilderFactory 331: 1 160 org.drools.core.impl.StatefulKnowledgeSessionImpl 332: 4 160 org.drools.core.reteoo.CompositeObjectSinkAdapter 333: 4 160 org.drools.core.rule.JavaDialectRuntimeData 334: 4 160 org.drools.core.rule.MVELDialectRuntimeData$MapFunctionResolverFactory 335: 2 160 org.mvel2.ast.Or 336: 10 160 org.mvel2.util.SimpleVariableSpaceModel 337: 4 160 sun.reflect.UnsafeQualifiedStaticIntegerFieldAccessorImpl 338: 5 160 sun.util.locale.provider.LocaleProviderAdapter$Type 339: 1 144 com.sample.ServiceOrder 340: 6 144 com.sun.org.apache.xerces.internal.util.Status 341: 1 144 java.text.DecimalFormat 342: 9 144 java.util.LinkedHashMap$LinkedValues 343: 3 144 java.util.TreeMap 344: 6 144 java.util.concurrent.ConcurrentSkipListMap$Node 345: 6 144 java.util.regex.Pattern$CharPropertyNames$2 346: 6 144 org.drools.compiler.lang.descr.AttributeDescr$Type 347: 6 144 org.drools.core.base.field.LongFieldImpl 348: 3 144 org.drools.core.rule.PredicateConstraint 349: 6 144 org.kie.internal.utils.ChainedProperties 350: 6 144 sun.misc.PerfCounter 351: 1 136 [Lcom.sun.org.apache.xerces.internal.impl.dv.xs.TypeValidator; 352: 7 128 [Lsun.reflect.generics.tree.TypeArgument; 353: 2 128 com.sun.org.apache.xerces.internal.impl.xpath.regex.RegularExpression 354: 2 128 java.io.ExpiringCache$1 355: 8 128 java.lang.Character 356: 8 128 java.lang.ThreadLocal 357: 4 128 java.lang.ref.WeakReference 358: 4 128 java.util.concurrent.ConcurrentSkipListMap$HeadIndex 359: 8 128 java.util.regex.Pattern$CharPropertyNames$3 360: 2 128 org.drools.core.SessionConfiguration 361: 4 128 org.drools.core.base.ClassFieldAccessorCache$CacheEntry 362: 1 128 org.drools.core.reteoo.AccumulateNode 363: 8 128 org.drools.core.reteoo.AlphaNode$AlphaMemory 364: 8 128 org.mvel2.conversion.ArrayHandler 365: 2 120 [Lcom.thoughtworks.xstream.io.xml.XmlFriendlyNameCoder$IntPair; 366: 5 120 [Lorg.drools.core.reteoo.ObjectSink; 367: 1 120 com.sun.org.apache.xerces.internal.impl.XMLEntityManager 368: 5 120 com.sun.org.apache.xerces.internal.impl.xs.traversers.LargeContainer 369: 5 120 com.sun.org.apache.xerces.internal.util.PropertyState 370: 5 120 com.sun.org.apache.xerces.internal.utils.XMLSecurityManager$State 371: 5 120 com.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager$State 372: 5 120 java.util.Collections$UnmodifiableRandomAccessList 373: 5 120 java.util.concurrent.ConcurrentHashMap$KeySetView 374: 5 120 java.util.concurrent.CopyOnWriteArrayList 375: 5 120 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject 376: 5 120 java.util.regex.Pattern$CharProperty$1 377: 5 120 java.util.regex.Pattern$Slice 378: 3 120 org.drools.core.common.LeftTupleSetsImpl 379: 5 120 org.drools.core.common.SingleBetaConstraints 380: 5 120 org.drools.core.factmodel.traits.TraitMapPropertyWrapperClassBuilderImpl 381: 5 120 org.drools.core.factmodel.traits.TraitMapProxyClassBuilderImpl 382: 5 120 org.drools.core.factmodel.traits.TraitTypeEnum 383: 1 120 org.drools.core.impl.KnowledgeBaseImpl 384: 5 120 org.drools.core.reteoo.ObjectSinkNodeList 385: 3 120 org.drools.core.util.TripleStore 386: 5 120 org.mvel2.optimizers.impl.refl.nodes.GetterAccessor 387: 3 120 sun.misc.FloatingDecimal$BinaryToASCIIBuffer 388: 5 120 sun.misc.FloatingDecimal$PreparedASCIIToBinaryBuffer 389: 3 120 sun.misc.URLClassPath 390: 2 112 [Lorg.eclipse.jdt.internal.compiler.lookup.LocalVariableBinding; 391: 2 112 org.drools.compiler.lang.descr.ImportDescr 392: 2 112 org.drools.compiler.lang.descr.NotDescr 393: 2 112 org.drools.compiler.rule.builder.dialect.java.JavaDialect 394: 2 112 org.drools.compiler.rule.builder.dialect.mvel.MVELDialect 395: 1 112 org.drools.core.reteoo.ExistsNode 396: 7 112 sun.reflect.generics.tree.ClassTypeSignature 397: 1 104 org.drools.compiler.lang.descr.CompositePackageDescr 398: 1 104 org.mvel2.optimizers.dynamic.DynamicOptimizer 399: 1 96 [Lcom.sun.org.apache.xerces.internal.impl.xpath.regex.RegularExpression; 400: 1 96 [Ljava.lang.invoke.MethodType; 401: 2 96 com.sample.OprOBBusAct 402: 4 96 com.sun.org.apache.xerces.internal.impl.xpath.regex.Token$ParenToken 403: 4 96 com.sun.org.apache.xerces.internal.impl.xpath.regex.Token$UnionToken 404: 3 96 com.sun.org.apache.xerces.internal.utils.XMLSecurityManager$NameMap 405: 4 96 com.thoughtworks.xstream.converters.basic.BooleanConverter 406: 4 96 com.thoughtworks.xstream.core.util.FastField 407: 3 96 java.io.FileOutputStream 408: 2 96 java.lang.ThreadGroup 409: 4 96 java.math.MathContext 410: 2 96 java.nio.HeapByteBuffer 411: 6 96 java.util.LinkedHashSet 412: 2 96 java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync 413: 3 96 java.util.regex.Pattern$Branch 414: 4 96 java.util.regex.Pattern$Ctype 415: 2 96 org.antlr.runtime.CommonToken 416: 4 96 org.drools.compiler.commons.jci.readers.MemoryResourceReader 417: 4 96 org.drools.core.base.ClassFieldAccessorStore 418: 3 96 org.drools.core.factmodel.traits.TraitFactory 419: 3 96 org.drools.core.phreak.RuleExecutor 420: 1 96 org.drools.core.reteoo.FromNodeLeftTuple 421: 4 96 org.drools.core.reteoo.ReteooFactHandleFactory 422: 4 96 org.drools.core.reteoo.RightTupleMemory$IndexType 423: 4 96 org.drools.core.rule.DialectRuntimeRegistry 424: 4 96 org.drools.core.rule.GroupElement$Type 425: 3 96 org.drools.core.rule.PredicateConstraint$PredicateContextEntry 426: 4 96 org.drools.core.rule.constraint.ConditionAnalyzer$FieldAccessInvocation 427: 4 96 org.drools.core.util.AbstractHashTable$DoubleCompositeIndex 428: 4 96 org.drools.core.util.BinaryHeapQueue 429: 4 96 sun.jvmstat.monitor.Variability 430: 2 96 sun.nio.cs.StreamEncoder 431: 1 96 sun.security.jca.ProviderList$1 432: 1 96 sun.security.provider.Sun 433: 3 96 sun.util.locale.provider.LocaleServiceProviderPool 434: 4 88 [Lcom.sun.org.apache.xerces.internal.impl.xs.XSGroupDecl; 435: 2 88 [Lcom.sun.org.apache.xerces.internal.utils.XMLSecurityManager$State; 436: 1 88 [Lorg.drools.compiler.rule.builder.dialect.java.parser.JavaBlockDescr$BlockType; 437: 5 88 [Lorg.eclipse.jdt.internal.compiler.lookup.ReferenceBinding; 438: 1 88 com.thoughtworks.xstream.XStream 439: 1 88 org.drools.compiler.builder.impl.KnowledgeBuilderImpl 440: 1 88 org.drools.core.common.DefaultAgenda 441: 1 88 sun.misc.Launcher$AppClassLoader 442: 1 88 sun.misc.Launcher$ExtClassLoader 443: 1 80 [Ljava.lang.invoke.LambdaForm; 444: 1 80 [Ljava.util.concurrent.RunnableScheduledFuture; 445: 3 80 [Ljava.util.regex.Pattern$Node; 446: 1 80 [Lorg.drools.compiler.lang.DroolsParaphraseTypes; 447: 3 80 [Lorg.drools.core.spi.BetaNodeFieldConstraint; 448: 2 80 com.sun.org.apache.xerces.internal.impl.dv.ValidatedInfo 449: 1 80 com.thoughtworks.xstream.core.util.CompositeClassLoader 450: 5 80 com.thoughtworks.xstream.mapper.DefaultMapper 451: 2 80 java.io.BufferedWriter 452: 2 80 java.io.ExpiringCache 453: 2 80 java.lang.ClassNotFoundException 454: 2 80 java.lang.invoke.MethodType 455: 1 80 java.net.URI 456: 2 80 java.util.Locale$Category 457: 2 80 java.util.PropertyResourceBundle 458: 1 80 java.util.concurrent.ScheduledThreadPoolExecutor 459: 5 80 org.drools.core.factmodel.DefaultBeanClassBuilder 460: 5 80 org.drools.core.factmodel.DefaultEnumClassBuilder 461: 5 80 org.drools.core.factmodel.traits.TraitClassBuilderImpl 462: 2 80 org.drools.core.reteoo.CompositeObjectSinkAdapter$FieldIndex 463: 1 80 org.drools.core.reteoo.LeftInputAdapterNode 464: 1 80 org.mvel2.optimizers.dynamic.DynamicClassLoader 465: 2 80 sun.reflect.UnsafeQualifiedStaticObjectFieldAccessorImpl 466: 2 80 sun.util.calendar.Era 467: 1 72 [Lorg.drools.compiler.lang.DroolsSentenceType; 468: 3 72 [Lorg.drools.core.common.BaseNode; 469: 3 72 [Lorg.drools.core.reteoo.SegmentMemory; 470: 1 72 [Lorg.drools.core.rule.constraint.ConditionAnalyzer$AritmeticOperator; 471: 2 72 [Lsun.security.jca.ProviderConfig; 472: 1 72 java.lang.invoke.MethodTypeForm 473: 3 72 java.net.InetAddress$InetAddressHolder 474: 3 72 java.util.Arrays$ArrayList 475: 1 72 java.util.ResourceBundle$RBClassLoader 476: 1 72 java.util.concurrent.ThreadPoolExecutor 477: 3 72 java.util.concurrent.atomic.AtomicMarkableReference$Pair 478: 3 72 java.util.regex.Pattern$Category 479: 3 72 java.util.regex.Pattern$Dollar 480: 3 72 org.drools.core.BeliefSystemType 481: 3 72 org.drools.core.base.ClassFieldAccessorCache 482: 3 72 org.drools.core.base.evaluators.AfterEvaluatorDefinition 483: 3 72 org.drools.core.base.evaluators.BeforeEvaluatorDefinition 484: 3 72 org.drools.core.base.evaluators.CoincidesEvaluatorDefinition 485: 3 72 org.drools.core.base.evaluators.DuringEvaluatorDefinition 486: 3 72 org.drools.core.base.evaluators.FinishedByEvaluatorDefinition 487: 3 72 org.drools.core.base.evaluators.FinishesEvaluatorDefinition 488: 3 72 org.drools.core.base.evaluators.IncludesEvaluatorDefinition 489: 3 72 org.drools.core.base.evaluators.MeetsEvaluatorDefinition 490: 3 72 org.drools.core.base.evaluators.MetByEvaluatorDefinition 491: 3 72 org.drools.core.base.evaluators.OverlappedByEvaluatorDefinition 492: 3 72 org.drools.core.base.evaluators.OverlapsEvaluatorDefinition 493: 3 72 org.drools.core.base.evaluators.StartedByEvaluatorDefinition 494: 3 72 org.drools.core.base.evaluators.StartsEvaluatorDefinition 495: 3 72 org.drools.core.base.mvel.MVELSalienceExpression 496: 3 72 org.drools.core.rule.ConsequenceMetaData$Statement 497: 3 72 org.drools.core.rule.ConsequenceMetaData$Statement$Type 498: 3 72 org.drools.core.rule.GroupElement$Type$ScopeDelimiter 499: 3 72 org.drools.core.rule.LineMappings 500: 3 72 org.drools.core.rule.TypeDeclaration$Kind 501: 3 72 org.drools.core.spi.Constraint$ConstraintType 502: 1 72 org.eclipse.jdt.internal.compiler.flow.UnconditionalFlowInfo 503: 1 72 org.eclipse.jdt.internal.compiler.lookup.ProblemReferenceBinding 504: 3 72 org.eclipse.jdt.internal.compiler.lookup.TypeConstants$CloseMethodRecord 505: 3 72 org.kie.internal.builder.ResultSeverity 506: 3 72 org.kie.internal.builder.conf.LanguageLevelOption 507: 3 72 org.kie.internal.builder.conf.PropertySpecificOption 508: 3 72 org.kie.internal.builder.conf.SessionCacheOption 509: 3 72 sun.misc.FloatingDecimal$ExceptionalBinaryToASCIIBuffer 510: 3 72 sun.misc.Signal 511: 3 72 sun.security.provider.NativePRNG$Variant 512: 1 72 sun.util.locale.provider.JRELocaleProviderAdapter 513: 3 72 sun.util.resources.ParallelListResourceBundle$KeySet 514: 1 64 [F 515: 2 64 [Lcom.sun.org.apache.xerces.internal.impl.XMLEntityManager$CharacterBuffer; 516: 2 64 [Lcom.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager$State; 517: 2 64 [Ljava.lang.Thread; 518: 1 64 [Lorg.drools.compiler.lang.DroolsEditorType; 519: 2 64 [Lorg.kie.internal.builder.conf.LanguageLevelOption; 520: 2 64 [Lorg.kie.internal.builder.conf.PropertySpecificOption; 521: 1 64 [Lsun.jvmstat.perfdata.monitor.v2_0.TypeCode; 522: 1 64 com.sun.org.apache.xerces.internal.impl.xs.SchemaGrammar$XSAnyType 523: 2 64 com.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager$Property 524: 1 64 com.thoughtworks.xstream.mapper.AnnotationMapper 525: 2 64 java.io.PrintStream 526: 2 64 java.lang.IllegalArgumentException 527: 2 64 java.lang.StringCoding$StringEncoder 528: 2 64 java.lang.VirtualMachineError 529: 2 64 java.lang.invoke.MethodType$ConcurrentWeakInternSet$WeakEntry 530: 2 64 java.lang.ref.ReferenceQueue$Null 531: 1 64 java.security.SecureRandom 532: 1 64 java.text.DateFormatSymbols 533: 1 64 java.text.DecimalFormatSymbols 534: 4 64 java.util.concurrent.ConcurrentSkipListSet 535: 2 64 java.util.concurrent.locks.AbstractQueuedSynchronizer$Node 536: 2 64 org.drools.compiler.commons.jci.compilers.EclipseJavaCompilerSettings 537: 2 64 org.drools.compiler.compiler.PackageRegistry 538: 1 64 org.drools.compiler.kie.builder.impl.ClasspathKieProject 539: 2 64 org.drools.compiler.kproject.ReleaseIdImpl 540: 2 64 org.drools.core.base.ClassTypeResolver 541: 2 64 org.drools.core.common.DoubleBetaConstraints 542: 1 64 org.drools.core.common.NamedEntryPoint 543: 4 64 org.drools.core.common.RuleBasePartitionId 544: 1 64 org.drools.core.impl.EnvironmentImpl$NullValueConcurrentHashMap 545: 1 64 org.drools.core.reteoo.EntryPointNode 546: 4 64 org.drools.core.rule.ImportDeclaration 547: 2 64 org.drools.core.util.AbstractHashTable$TripleCompositeIndex 548: 1 64 org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$1 549: 4 64 org.kie.internal.utils.ServiceRegistryImpl$ReturnInstance 550: 4 64 sun.net.www.protocol.jar.Handler 551: 2 64 sun.reflect.generics.repository.ClassRepository 552: 1 56 [Lcom.sun.org.apache.xerces.internal.impl.dv.XSSimpleType; 553: 1 56 [Lcom.sun.org.apache.xerces.internal.impl.xs.util.XInt; 554: 1 56 [Lorg.drools.core.rule.constraint.ConditionAnalyzer$BooleanOperator; 555: 1 56 com.sun.org.apache.xerces.internal.impl.XMLEntityScanner 556: 1 56 java.lang.invoke.MemberName 557: 1 56 org.drools.compiler.kie.builder.impl.FileKieModule 558: 1 56 org.drools.compiler.kproject.models.KieBaseModelImpl 559: 1 56 org.drools.compiler.kproject.models.KieSessionModelImpl 560: 1 56 org.drools.compiler.lang.descr.CollectDescr 561: 1 56 org.drools.core.common.AgendaGroupQueueImpl 562: 1 56 org.drools.core.reteoo.Rete 563: 1 56 sun.jvmstat.perfdata.monitor.protocol.local.LocalVmManager 564: 1 56 sun.security.provider.SHA 565: 1 48 [Lcom.sun.org.apache.xerces.internal.utils.XMLSecurityManager$Limit; 566: 3 48 [Ljava.lang.annotation.Annotation; 567: 1 48 [Ljava.math.RoundingMode; 568: 2 48 [Ljava.net.InetAddress; 569: 1 48 [Ljava.util.concurrent.TimeUnit; 570: 1 48 [Lorg.drools.core.util.index.IndexUtil$ConstraintType; 571: 3 48 [Lorg.eclipse.jdt.internal.compiler.lookup.FieldBinding; 572: 3 48 [Lorg.eclipse.jdt.internal.compiler.lookup.VariableBinding; 573: 1 48 [Lsun.jvmstat.monitor.Units; 574: 2 48 [Lsun.reflect.generics.tree.ClassTypeSignature; 575: 2 48 [Lsun.util.calendar.Era; 576: 1 48 com.sample.OprOBServiceOrder 577: 3 48 com.sun.org.apache.xerces.internal.impl.dv.dtd.ListDatatypeValidator 578: 1 48 com.sun.org.apache.xerces.internal.util.URI 579: 3 48 com.thoughtworks.xstream.converters.extended.JavaClassConverter 580: 2 48 com.thoughtworks.xstream.converters.extended.TextAttributeConverter 581: 3 48 com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker 582: 2 48 java.io.BufferedOutputStream 583: 2 48 java.io.File$PathStatus 584: 2 48 java.io.OutputStreamWriter 585: 2 48 java.lang.ThreadLocal$ThreadLocalMap 586: 2 48 java.net.Inet4Address 587: 2 48 java.net.InetAddress$Cache 588: 2 48 java.net.InetAddress$Cache$Type 589: 2 48 java.net.InetAddress$CacheEntry 590: 2 48 java.nio.charset.CoderResult 591: 3 48 java.nio.charset.CodingErrorAction 592: 3 48 java.text.AttributedCharacterIterator$Attribute 593: 2 48 java.util.BitSet 594: 3 48 java.util.ResourceBundle$NoFallbackControl 595: 3 48 java.util.concurrent.ConcurrentHashMap$ValuesView 596: 2 48 java.util.concurrent.ConcurrentLinkedQueue 597: 2 48 java.util.concurrent.ConcurrentLinkedQueue$Node 598: 1 48 java.util.concurrent.LinkedBlockingQueue 599: 3 48 java.util.concurrent.atomic.AtomicMarkableReference 600: 2 48 java.util.concurrent.locks.ReentrantReadWriteLock 601: 2 48 java.util.regex.Pattern$7 602: 3 48 java.util.regex.Pattern$Begin 603: 3 48 java.util.regex.Pattern$BranchConn 604: 3 48 java.util.regex.Pattern$Dot 605: 1 48 org.drools.compiler.builder.impl.TypeDeclarationBuilder 606: 2 48 org.drools.compiler.commons.jci.compilers.EclipseJavaCompiler 607: 1 48 org.drools.compiler.commons.jci.compilers.EclipseJavaCompilerSettings$1 608: 1 48 org.drools.compiler.kie.builder.impl.FormatsManager$1 609: 2 48 org.drools.compiler.lang.descr.ExprConstraintDescr$Type 610: 2 48 org.drools.compiler.rule.builder.DroolsCompilerComponentFactory 611: 2 48 org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration 612: 2 48 org.drools.compiler.rule.builder.dialect.java.PackageStore 613: 2 48 org.drools.compiler.rule.builder.dialect.mvel.MVELDialectConfiguration 614: 2 48 org.drools.core.base.AccessorKey$AccessorType 615: 3 48 org.drools.core.base.DefaultKnowledgeHelperFactory 616: 2 48 org.drools.core.base.evaluators.EvaluatorRegistry 617: 2 48 org.drools.core.base.evaluators.MatchesEvaluatorsDefinition$1 618: 2 48 org.drools.core.base.evaluators.SetEvaluatorsDefinition$1 619: 1 48 org.drools.core.base.evaluators.SetEvaluatorsDefinition$2 620: 2 48 org.drools.core.base.evaluators.SoundslikeEvaluatorsDefinition$1 621: 3 48 org.drools.core.base.field.BooleanFieldImpl 622: 3 48 org.drools.core.common.DefaultAgendaFactory 623: 3 48 org.drools.core.common.PhreakBeliefSystemFactory 624: 3 48 org.drools.core.common.PhreakPropagationContextFactory 625: 3 48 org.drools.core.common.PhreakWorkingMemoryFactory 626: 2 48 org.drools.core.factmodel.traits.VirtualPropertyMode 627: 1 48 org.drools.core.io.impl.ByteArrayResource 628: 3 48 org.drools.core.reteoo.ReteooRuleBuilderFactory 629: 3 48 org.drools.core.reteoo.builder.PhreakNodeFactory 630: 3 48 org.drools.core.rule.ConsequenceMetaData 631: 3 48 org.drools.core.rule.DefaultLogicTransformerFactory 632: 2 48 org.drools.core.rule.TypeDeclaration$Format 633: 2 48 org.drools.core.rule.TypeDeclaration$Nature 634: 1 48 org.drools.core.rule.builder.dialect.asm.ClassGenerator$InternalTypeResolver$1 635: 2 48 org.drools.core.rule.constraint.ConditionAnalyzer$FixedExpression 636: 2 48 org.drools.core.util.ObjectHashSet$ObjectEntry 637: 3 48 org.drools.core.util.TripleFactoryImpl 638: 3 48 org.drools.core.util.TripleStore$TripleKeyComparator 639: 1 48 org.eclipse.jdt.internal.compiler.flow.FlowContext 640: 2 48 org.eclipse.jdt.internal.compiler.impl.LongConstant 641: 1 48 org.eclipse.jdt.internal.compiler.lookup.FieldBinding 642: 1 48 org.eclipse.jdt.internal.compiler.lookup.ProblemPackageBinding 643: 2 48 org.kie.api.builder.model.KieSessionModel$KieSessionType 644: 2 48 org.kie.api.conf.DeclarativeAgendaOption 645: 2 48 org.kie.api.conf.EqualityBehaviorOption 646: 2 48 org.kie.api.conf.EventProcessingOption 647: 2 48 org.kie.api.conf.MBeansOption 648: 2 48 org.kie.api.definition.type.Role$Type 649: 2 48 org.kie.api.runtime.conf.QueryListenerOption 650: 2 48 org.kie.internal.builder.conf.RuleEngineOption 651: 2 48 org.kie.internal.conf.IndexPrecedenceOption 652: 2 48 sun.misc.NativeSignalHandler 653: 3 48 sun.reflect.BootstrapConstructorAccessorImpl 654: 2 48 sun.reflect.generics.tree.ClassSignature 655: 2 48 sun.security.jca.ProviderList 656: 2 48 sun.security.jca.ProviderList$3 657: 1 48 sun.text.resources.FormatData 658: 1 48 sun.text.resources.en.FormatData_en 659: 1 48 sun.text.resources.en.FormatData_en_US 660: 1 48 sun.util.resources.CalendarData 661: 1 48 sun.util.resources.CurrencyNames 662: 1 48 sun.util.resources.TimeZoneNames 663: 1 48 sun.util.resources.en.CalendarData_en 664: 1 48 sun.util.resources.en.CurrencyNames_en_US 665: 1 48 sun.util.resources.en.TimeZoneNames_en 666: 1 40 [Lcom.sun.org.apache.xerces.internal.util.Status; 667: 2 40 [Lcom.sun.org.apache.xerces.internal.xni.grammars.Grammar; 668: 1 40 [Lcom.thoughtworks.xstream.core.util.ThreadSafeSimpleDateFormat; 669: 1 40 [Ljava.lang.management.MemoryPoolMXBean; 670: 2 40 [Ljava.security.ProtectionDomain; 671: 1 40 [Lorg.drools.compiler.lang.descr.AttributeDescr$Type; 672: 1 40 [Lorg.drools.compiler.lang.descr.ConnectiveType; 673: 1 40 [Lorg.drools.core.factmodel.traits.TraitTypeEnum; 674: 1 40 [Lorg.eclipse.jdt.internal.compiler.codegen.BranchLabel; 675: 1 40 [Lorg.eclipse.jdt.internal.compiler.codegen.ExceptionLabel; 676: 2 40 [Lsun.reflect.generics.tree.FormalTypeParameter; 677: 1 40 [Lsun.util.locale.provider.LocaleProviderAdapter$Type; 678: 1 40 [[[C 679: 1 40 com.sun.org.apache.xerces.internal.impl.XMLEntityManager$CharacterBufferPool 680: 1 40 com.sun.org.apache.xerces.internal.impl.XMLErrorReporter 681: 1 40 com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl 682: 1 40 com.sun.org.apache.xerces.internal.utils.XMLSecurityManager 683: 1 40 com.sun.xml.internal.stream.XMLEntityStorage 684: 1 40 com.sun.xml.internal.stream.util.BufferAllocator 685: 1 40 com.thoughtworks.xstream.mapper.AttributeMapper 686: 1 40 java.io.BufferedInputStream 687: 1 40 java.text.DigitList 688: 1 40 java.util.ResourceBundle$1 689: 1 40 org.drools.compiler.kie.builder.impl.KieContainerImpl 690: 1 40 org.drools.core.base.DefaultKnowledgeHelper 691: 1 40 org.drools.core.common.SynchronizedLeftTupleSets 692: 1 40 org.drools.core.common.UpgradableReentrantReadWriteLock 693: 1 40 org.drools.core.reteoo.AccumulateNode$AccumulateContext 694: 1 40 org.drools.core.reteoo.AccumulateNode$SingleAccumulateMemory 695: 1 40 org.drools.core.reteoo.LeftInputAdapterNode$LiaNodeMemory 696: 1 40 org.drools.core.util.ObjectHashMap 697: 1 40 sun.jvmstat.perfdata.monitor.protocol.local.MonitoredHostProvider 698: 1 40 sun.misc.Cleaner 699: 1 40 sun.nio.cs.StandardCharsets$Aliases 700: 1 40 sun.nio.cs.StandardCharsets$Cache 701: 1 40 sun.nio.cs.StandardCharsets$Classes 702: 1 40 sun.nio.cs.UTF_8$Decoder 703: 1 40 sun.tools.attach.LinuxVirtualMachine 704: 1 32 [Lcom.sun.org.apache.xerces.internal.impl.dv.xs.AbstractDateTimeDV$DateTimeData; 705: 1 32 [Lcom.sun.org.apache.xerces.internal.utils.XMLSecurityManager$NameMap; 706: 1 32 [Lcom.thoughtworks.xstream.core.util.FastField; 707: 2 32 [Ljava.lang.Enum; 708: 1 32 [Ljava.lang.OutOfMemoryError; 709: 2 32 [Ljava.lang.StackTraceElement; 710: 1 32 [Ljava.lang.ThreadGroup; 711: 1 32 [Lorg.drools.core.BeliefSystemType; 712: 1 32 [Lorg.drools.core.TimerJobFactoryType; 713: 1 32 [Lorg.drools.core.reteoo.RightTupleMemory$IndexType; 714: 1 32 [Lorg.drools.core.rule.ConsequenceMetaData$Statement$Type; 715: 1 32 [Lorg.drools.core.rule.GroupElement$Type$ScopeDelimiter; 716: 1 32 [Lorg.drools.core.rule.GroupElement$Type; 717: 1 32 [Lorg.drools.core.rule.TypeDeclaration$Kind; 718: 1 32 [Lorg.drools.core.spi.Constraint$ConstraintType; 719: 2 32 [Lorg.eclipse.jdt.internal.compiler.lookup.MethodBinding; 720: 2 32 [Lorg.eclipse.jdt.internal.compiler.lookup.TypeBinding; 721: 1 32 [Lorg.eclipse.jdt.internal.compiler.lookup.TypeConstants$CloseMethodRecord; 722: 1 32 [Lorg.kie.internal.builder.ResultSeverity; 723: 1 32 [Lorg.kie.internal.builder.conf.SessionCacheOption; 724: 1 32 [Lsun.jvmstat.monitor.Variability; 725: 1 32 [Lsun.security.provider.NativePRNG$Variant; 726: 2 32 com.sample.OprAutomatedActivityGraphConstructionPacket 727: 1 32 com.sun.org.apache.xerces.internal.impl.XMLEntityScanner$1 728: 2 32 com.sun.org.apache.xerces.internal.impl.dv.dtd.ENTITYDatatypeValidator 729: 2 32 com.sun.org.apache.xerces.internal.impl.dv.xs.QNameDV 730: 2 32 com.sun.org.apache.xerces.internal.impl.xpath.regex.Token 731: 2 32 com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl 732: 1 32 com.sun.org.apache.xerces.internal.jaxp.validation.SimpleXMLSchema 733: 1 32 com.sun.org.apache.xerces.internal.util.AugmentationsImpl$SmallContainer 734: 1 32 com.sun.org.apache.xerces.internal.util.XMLResourceIdentifierImpl 735: 2 32 com.thoughtworks.xstream.converters.basic.ByteConverter 736: 1 32 com.thoughtworks.xstream.converters.basic.DateConverter 737: 1 32 com.thoughtworks.xstream.converters.extended.LookAndFeelConverter 738: 1 32 com.thoughtworks.xstream.converters.reflection.ReflectionConverter 739: 1 32 com.thoughtworks.xstream.converters.reflection.SerializableConverter 740: 1 32 com.thoughtworks.xstream.io.xml.XmlFriendlyNameCoder 741: 1 32 com.thoughtworks.xstream.mapper.ClassAliasingMapper 742: 1 32 com.thoughtworks.xstream.mapper.FieldAliasingMapper 743: 1 32 java.io.UnixFileSystem 744: 1 32 java.lang.ArithmeticException 745: 2 32 java.lang.Boolean 746: 1 32 java.lang.ClassCastException 747: 1 32 java.lang.NullPointerException 748: 1 32 java.lang.StringCoding$StringDecoder 749: 1 32 java.net.Socket 750: 2 32 java.nio.ByteOrder 751: 1 32 java.security.MessageDigest$Delegate 752: 2 32 java.util.IdentityHashMap$EntrySet 753: 2 32 java.util.LinkedHashMap$LinkedEntrySet 754: 2 32 java.util.ResourceBundle$SingleFormatControl 755: 2 32 java.util.WeakHashMap$KeySet 756: 1 32 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue 757: 1 32 java.util.concurrent.ThreadLocalRandom 758: 2 32 java.util.concurrent.atomic.AtomicReference 759: 1 32 java.util.concurrent.atomic.AtomicReferenceFieldUpdater$AtomicReferenceFieldUpdaterImpl 760: 2 32 java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock 761: 2 32 java.util.concurrent.locks.ReentrantReadWriteLock$Sync$ThreadLocalHoldCounter 762: 2 32 java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock 763: 1 32 java.util.regex.Pattern$BnM 764: 2 32 java.util.regex.Pattern$Caret 765: 2 32 javax.xml.validation.SecuritySupport 766: 2 32 org.drools.compiler.compiler.DialectCompiletimeRegistry 767: 2 32 org.drools.compiler.kie.builder.impl.KieRepositoryImpl$ComparableVersion$IntegerItem 768: 1 32 org.drools.compiler.kie.builder.impl.KieServicesImpl 769: 2 32 org.drools.compiler.lang.MVELDumper 770: 2 32 org.drools.compiler.rule.builder.CollectBuilder 771: 2 32 org.drools.compiler.rule.builder.ConditionalBranchBuilder 772: 2 32 org.drools.compiler.rule.builder.DefaultConstraintBuilderFactory 773: 2 32 org.drools.compiler.rule.builder.EntryPointBuilder 774: 2 32 org.drools.compiler.rule.builder.ForallBuilder 775: 2 32 org.drools.compiler.rule.builder.GroupElementBuilder 776: 2 32 org.drools.compiler.rule.builder.NamedConsequenceBuilder 777: 2 32 org.drools.compiler.rule.builder.PatternBuilder 778: 2 32 org.drools.compiler.rule.builder.QueryBuilder 779: 2 32 org.drools.compiler.rule.builder.WindowReferenceBuilder 780: 2 32 org.drools.compiler.rule.builder.dialect.java.JavaFunctionBuilder 781: 2 32 org.drools.compiler.rule.builder.dialect.mvel.MVELEnabledBuilder 782: 2 32 org.drools.compiler.rule.builder.dialect.mvel.MVELFromBuilder 783: 2 32 org.drools.compiler.rule.builder.dialect.mvel.MVELSalienceBuilder 784: 2 32 org.drools.core.RuleBaseConfiguration$AssertBehaviour 785: 2 32 org.drools.core.RuleBaseConfiguration$SequentialAgenda 786: 2 32 org.drools.core.base.EnabledBoolean 787: 2 32 org.drools.core.base.accumulators.AverageAccumulateFunction 788: 2 32 org.drools.core.base.accumulators.BigDecimalAverageAccumulateFunction 789: 2 32 org.drools.core.base.accumulators.BigDecimalSumAccumulateFunction 790: 2 32 org.drools.core.base.accumulators.CollectListAccumulateFunction 791: 2 32 org.drools.core.base.accumulators.CollectSetAccumulateFunction 792: 2 32 org.drools.core.base.accumulators.CountAccumulateFunction 793: 2 32 org.drools.core.base.accumulators.MaxAccumulateFunction 794: 2 32 org.drools.core.base.accumulators.MinAccumulateFunction 795: 2 32 org.drools.core.base.accumulators.SumAccumulateFunction 796: 2 32 org.drools.core.base.evaluators.MatchesEvaluatorsDefinition 797: 2 32 org.drools.core.base.evaluators.SetEvaluatorsDefinition 798: 2 32 org.drools.core.base.evaluators.SoundslikeEvaluatorsDefinition 799: 1 32 org.drools.core.common.QuadroupleBetaConstraints 800: 1 32 org.drools.core.common.SingleThreadedObjectStore 801: 2 32 org.drools.core.conflict.PhreakConflictResolver 802: 1 32 org.drools.core.reteoo.ReteooBuilder 803: 2 32 org.drools.core.reteoo.builder.AccumulateBuilder 804: 1 32 org.drools.core.rule.SingleAccumulate 805: 2 32 org.drools.core.type.DateFormatsImpl 806: 1 32 org.drools.core.util.HashTableIterator 807: 2 32 org.eclipse.jdt.internal.compiler.impl.BooleanConstant 808: 1 32 org.eclipse.jdt.internal.compiler.util.HashtableOfInt 809: 2 32 org.kie.api.runtime.conf.TimedRuleExectionOption 810: 2 32 org.kie.internal.builder.conf.DefaultDialectOption 811: 2 32 org.kie.internal.runtime.conf.ForceEagerActivationOption 812: 1 32 org.kie.internal.utils.ServiceRegistryImpl 813: 2 32 org.mvel2.templates.SimpleTemplateRegistry 814: 1 32 sun.management.MemoryImpl 815: 1 32 sun.nio.cs.StandardCharsets 816: 1 32 sun.reflect.generics.reflectiveObjects.TypeVariableImpl 817: 2 32 sun.reflect.generics.tree.TypeVariableSignature 818: 1 32 sun.security.provider.SecureRandom 819: 1 32 sun.util.locale.provider.LocaleResources 820: 1 24 [Lcom.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager$Property; 821: 1 24 [Ljava.io.File$PathStatus; 822: 1 24 [Ljava.lang.invoke.MethodHandle; 823: 1 24 [Ljava.lang.reflect.TypeVariable; 824: 1 24 [Ljava.net.InetAddress$Cache$Type; 825: 1 24 [Ljava.util.Locale$Category; 826: 1 24 [Lorg.drools.compiler.lang.descr.ExprConstraintDescr$Type; 827: 1 24 [Lorg.drools.core.ClockType; 828: 1 24 [Lorg.drools.core.base.AccessorKey$AccessorType; 829: 1 24 [Lorg.drools.core.factmodel.traits.VirtualPropertyMode; 830: 1 24 [Lorg.drools.core.rule.TypeDeclaration$Format; 831: 1 24 [Lorg.drools.core.rule.TypeDeclaration$Nature; 832: 1 24 [Lorg.drools.core.spi.AlphaNodeFieldConstraint; 833: 1 24 [Lorg.kie.api.builder.model.KieSessionModel$KieSessionType; 834: 1 24 [Lorg.kie.api.conf.DeclarativeAgendaOption; 835: 1 24 [Lorg.kie.api.conf.EqualityBehaviorOption; 836: 1 24 [Lorg.kie.api.conf.EventProcessingOption; 837: 1 24 [Lorg.kie.api.conf.MBeansOption; 838: 1 24 [Lorg.kie.api.definition.type.Role$Type; 839: 1 24 [Lorg.kie.api.marshalling.ObjectMarshallingStrategy; 840: 1 24 [Lorg.kie.api.runtime.conf.QueryListenerOption; 841: 1 24 [Lorg.kie.internal.builder.conf.RuleEngineOption; 842: 1 24 [Lorg.kie.internal.conf.IndexPrecedenceOption; 843: 1 24 [Lorg.mvel2.ConversionHandler; 844: 1 24 [Lsun.launcher.LauncherHelper; 845: 1 24 [Lsun.reflect.generics.tree.FieldTypeSignature; 846: 1 24 com.sample.OprOBActionGroupSOsIntoIOPs 847: 1 24 com.sample.OprOBProductCodeProductType 848: 1 24 com.sun.org.apache.xerces.internal.impl.Constants$ArrayEnumeration 849: 1 24 com.sun.org.apache.xerces.internal.impl.xs.XSMessageFormatter 850: 1 24 com.sun.org.apache.xerces.internal.util.SymbolTable 851: 1 24 com.sun.org.apache.xerces.internal.utils.XMLSecurityPropertyManager 852: 1 24 com.thoughtworks.xstream.converters.basic.StringConverter 853: 1 24 com.thoughtworks.xstream.converters.collections.CollectionConverter 854: 1 24 com.thoughtworks.xstream.converters.collections.MapConverter 855: 1 24 com.thoughtworks.xstream.converters.collections.SingletonCollectionConverter 856: 1 24 com.thoughtworks.xstream.converters.collections.SingletonMapConverter 857: 1 24 com.thoughtworks.xstream.converters.collections.TreeMapConverter 858: 1 24 com.thoughtworks.xstream.converters.collections.TreeSetConverter 859: 1 24 com.thoughtworks.xstream.converters.collections.TreeSetConverter$1 860: 1 24 com.thoughtworks.xstream.converters.enums.EnumMapConverter 861: 1 24 com.thoughtworks.xstream.converters.extended.DynamicProxyConverter 862: 1 24 com.thoughtworks.xstream.converters.extended.FontConverter 863: 1 24 com.thoughtworks.xstream.converters.extended.JavaFieldConverter 864: 1 24 com.thoughtworks.xstream.converters.extended.ThrowableConverter 865: 1 24 com.thoughtworks.xstream.converters.reflection.ExternalizableConverter 866: 1 24 com.thoughtworks.xstream.converters.reflection.FieldDictionary 867: 1 24 com.thoughtworks.xstream.converters.reflection.SunUnsafeReflectionProvider 868: 1 24 com.thoughtworks.xstream.core.DefaultConverterLookup 869: 1 24 com.thoughtworks.xstream.core.util.PrioritizedList 870: 1 24 com.thoughtworks.xstream.core.util.SelfStreamingInstanceChecker 871: 1 24 com.thoughtworks.xstream.core.util.WeakCache 872: 1 24 com.thoughtworks.xstream.io.path.Path 873: 1 24 com.thoughtworks.xstream.io.xml.DomDriver 874: 1 24 com.thoughtworks.xstream.mapper.AttributeAliasingMapper 875: 1 24 com.thoughtworks.xstream.mapper.CachingMapper 876: 1 24 com.thoughtworks.xstream.mapper.DefaultImplementationsMapper 877: 1 24 com.thoughtworks.xstream.mapper.DynamicProxyMapper 878: 1 24 com.thoughtworks.xstream.mapper.EnumMapper 879: 1 24 com.thoughtworks.xstream.mapper.ImmutableTypesMapper 880: 1 24 com.thoughtworks.xstream.mapper.ImplicitCollectionMapper 881: 1 24 com.thoughtworks.xstream.mapper.LocalConversionMapper 882: 1 24 com.thoughtworks.xstream.mapper.OuterClassMapper 883: 1 24 com.thoughtworks.xstream.mapper.PackageAliasingMapper 884: 1 24 com.thoughtworks.xstream.mapper.SecurityMapper 885: 1 24 com.thoughtworks.xstream.mapper.SystemAttributeAliasingMapper 886: 1 24 java.lang.Long 887: 1 24 java.lang.StringBuilder 888: 1 24 java.lang.invoke.LambdaForm$NamedFunction 889: 1 24 java.lang.invoke.MethodType$ConcurrentWeakInternSet 890: 1 24 java.lang.reflect.ReflectPermission 891: 1 24 java.math.MutableBigInteger 892: 1 24 java.net.Inet6AddressImpl 893: 1 24 java.net.InetAddress 894: 1 24 java.net.ServerSocket 895: 1 24 java.util.Collections$EmptyMap 896: 1 24 java.util.Collections$SetFromMap 897: 1 24 java.util.Collections$SynchronizedCollection 898: 1 24 java.util.Currency 899: 1 24 java.util.Locale$Cache 900: 1 24 java.util.ResourceBundle$Control$CandidateListCache 901: 1 24 java.util.concurrent.Executors$DefaultThreadFactory 902: 1 24 java.util.concurrent.LinkedBlockingQueue$Node 903: 1 24 java.util.concurrent.TimeUnit$1 904: 1 24 java.util.concurrent.TimeUnit$2 905: 1 24 java.util.concurrent.TimeUnit$3 906: 1 24 java.util.concurrent.TimeUnit$4 907: 1 24 java.util.concurrent.TimeUnit$5 908: 1 24 java.util.concurrent.TimeUnit$6 909: 1 24 java.util.concurrent.TimeUnit$7 910: 1 24 org.drools.base.com.sample.OprOBActionGroupSOsIntoIOPs1561063579$getObjectId 911: 1 24 org.drools.base.com.sample.OprOBActionGroupSOsIntoIOPs1561063579$getObjectId 912: 1 24 org.drools.base.com.sample.OprOBActionGroupSOsIntoIOPs1561063579$isComputed 913: 1 24 org.drools.base.com.sample.OprOBActionGroupSOsIntoIOPs1561063579$isComputed 914: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getActivityId 915: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getActivityId 916: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getAddressId 917: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getAddressId 918: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getRootId 919: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getRootId 920: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getStatus 921: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getStatus 922: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getType 923: 1 24 org.drools.base.com.sample.OprOBBusAct1345900725$getType 924: 1 24 org.drools.base.com.sample.OprOBProductCodeProductType1753714541$getProductCode 925: 1 24 org.drools.base.com.sample.OprOBProductCodeProductType1753714541$getProductCode 926: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getAddressId 927: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getAddressId 928: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getDesiredScheduleTypeRD 929: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getDesiredScheduleTypeRD 930: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getInternalOrderId 931: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getInternalOrderId 932: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getInternalOrderPositionId 933: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getInternalOrderPositionId 934: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getProductCode 935: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getProductCode 936: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getUsageModeValueRD 937: 1 24 org.drools.base.com.sample.OprOBServiceOrder1732238286$getUsageModeValueRD 938: 1 24 org.drools.base.java.util.ArrayList1627960023$size 939: 1 24 org.drools.base.java.util.ArrayList1627960023$size 940: 1 24 org.drools.compiler.builder.impl.TypeDeclarationCache 941: 1 24 org.drools.compiler.builder.impl.TypeDeclarationConfigurator 942: 1 24 org.drools.compiler.kie.builder.impl.FormatsManager 943: 1 24 org.drools.compiler.kie.builder.impl.KieRepositoryImpl 944: 1 24 org.drools.compiler.kie.builder.impl.KieRepositoryImpl$ComparableVersion 945: 1 24 org.drools.compiler.kie.builder.impl.KieRepositoryImpl$ComparableVersion$ListItem 946: 1 24 org.drools.compiler.kie.builder.impl.KieRepositoryImpl$KieModuleRepo 947: 1 24 org.drools.compiler.kie.builder.impl.ResultsImpl 948: 1 24 org.drools.compiler.kproject.models.KieModuleModelImpl 949: 1 24 org.drools.core.ClockType$1 950: 1 24 org.drools.core.ClockType$2 951: 1 24 org.drools.core.TimerJobFactoryType$1 952: 1 24 org.drools.core.TimerJobFactoryType$2 953: 1 24 org.drools.core.TimerJobFactoryType$3 954: 1 24 org.drools.core.base.MapGlobalResolver 955: 1 24 org.drools.core.base.accumulators.CollectAccumulator 956: 1 24 org.drools.core.base.evaluators.MatchesEvaluatorsDefinition$StringMatchesEvaluator 957: 1 24 org.drools.core.base.evaluators.MatchesEvaluatorsDefinition$StringNotMatchesEvaluator 958: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ArrayContainsEvaluator 959: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ArrayExcludesEvaluator 960: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BigDecimalMemberOfEvaluator 961: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BigDecimalNotMemberOfEvaluator 962: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BigIntegerMemberOfEvaluator 963: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BigIntegerNotMemberOfEvaluator 964: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BooleanMemberOfEvaluator 965: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BooleanNotMemberOfEvaluator 966: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ByteMemberOfEvaluator 967: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ByteNotMemberOfEvaluator 968: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$CharacterMemberOfEvaluator 969: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$CharacterNotMemberOfEvaluator 970: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$DateMemberOfEvaluator 971: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$DateNotMemberOfEvaluator 972: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$DoubleMemberOfEvaluator 973: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$DoubleNotMemberOfEvaluator 974: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$FloatMemberOfEvaluator 975: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$FloatNotMemberOfEvaluator 976: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$IntegerMemberOfEvaluator 977: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$IntegerNotMemberOfEvaluator 978: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$LongMemberOfEvaluator 979: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$LongNotMemberOfEvaluator 980: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ObjectContainsEvaluator 981: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ObjectExcludesEvaluator 982: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ObjectMemberOfEvaluator 983: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ObjectNotMemberOfEvaluator 984: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ShortMemberOfEvaluator 985: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ShortNotMemberOfEvaluator 986: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$StringMemberOfEvaluator 987: 1 24 org.drools.core.base.evaluators.SetEvaluatorsDefinition$StringNotMemberOfEvaluator 988: 1 24 org.drools.core.base.evaluators.SoundslikeEvaluatorsDefinition$StringNotSoundsLikeEvaluator 989: 1 24 org.drools.core.base.evaluators.SoundslikeEvaluatorsDefinition$StringSoundsLikeEvaluator 990: 1 24 org.drools.core.common.ConcurrentNodeMemories 991: 1 24 org.drools.core.common.ObjectTypeConfigurationRegistry 992: 1 24 org.drools.core.common.UpgradableReentrantReadWriteLock$1 993: 1 24 org.drools.core.event.KieBaseEventSupport 994: 1 24 org.drools.core.impl.EnvironmentImpl 995: 1 24 org.drools.core.marshalling.impl.SerializablePlaceholderResolverStrategy 996: 1 24 org.drools.core.reteoo.CompositeLeftTupleSinkAdapter 997: 1 24 org.drools.core.reteoo.LeftTupleSinkNodeList 998: 1 24 org.drools.core.reteoo.ReteooBuilder$IdGenerator 999: 1 24 org.drools.core.reteoo.SegmentMemory$LiaMemoryPrototype 1000: 1 24 org.drools.core.rule.Collect 1001: 1 24 org.drools.core.rule.builder.dialect.asm.ClassGenerator$2 1002: 1 24 org.drools.core.rule.constraint.ConditionAnalyzer$VariableExpression 1003: 1 24 org.drools.core.time.impl.JDKTimerService 1004: 1 24 org.eclipse.jdt.internal.compiler.impl.DoubleConstant 1005: 1 24 org.kie.internal.runtime.beliefs.KieBeliefsImpl 1006: 1 24 org.kie.internal.utils.ServiceRegistryImpl$FactoryInstantiator 1007: 1 24 org.mvel2.debug.DebuggerContext 1008: 1 24 org.mvel2.optimizers.impl.refl.nodes.StaticVarAccessor 1009: 1 24 sun.launcher.LauncherHelper 1010: 1 24 sun.management.RuntimeImpl 1011: 1 24 sun.management.VMManagementImpl 1012: 1 24 sun.misc.JarIndex 1013: 1 24 sun.misc.Perf$1 1014: 1 24 sun.misc.URLClassPath$FileLoader 1015: 1 24 sun.net.ProgressMonitor 1016: 1 24 sun.net.sdp.SdpProvider 1017: 1 24 sun.nio.cs.ISO_8859_1 1018: 1 24 sun.nio.cs.US_ASCII 1019: 1 24 sun.nio.cs.UTF_16 1020: 1 24 sun.nio.cs.UTF_16BE 1021: 1 24 sun.nio.cs.UTF_16LE 1022: 1 24 sun.nio.cs.UTF_8 1023: 1 24 sun.reflect.generics.factory.CoreReflectionFactory 1024: 1 24 sun.reflect.generics.scope.ClassScope 1025: 1 24 sun.reflect.generics.tree.FormalTypeParameter 1026: 1 24 sun.util.locale.BaseLocale$Cache 1027: 1 24 sun.util.locale.provider.CalendarDataProviderImpl 1028: 1 24 sun.util.locale.provider.CalendarProviderImpl 1029: 1 24 sun.util.locale.provider.CurrencyNameProviderImpl 1030: 1 24 sun.util.locale.provider.DateFormatSymbolsProviderImpl 1031: 1 24 sun.util.locale.provider.DecimalFormatSymbolsProviderImpl 1032: 1 24 sun.util.locale.provider.NumberFormatProviderImpl 1033: 1 24 sun.util.locale.provider.TimeZoneNameProviderImpl 1034: 1 16 [Lcom.sun.org.apache.xerces.internal.impl.xs.SubstitutionGroupHandler$OneSubGroup; 1035: 1 16 [Ljava.beans.EventSetDescriptor; 1036: 1 16 [Ljava.lang.Throwable; 1037: 1 16 [Ljava.security.Provider; 1038: 1 16 [Ljava.security.cert.Certificate; 1039: 1 16 [Ljava.text.FieldPosition; 1040: 1 16 [Lorg.eclipse.jdt.internal.compiler.ast.Argument; 1041: 1 16 [Lorg.eclipse.jdt.internal.compiler.ast.TypeReference; 1042: 1 16 [Lorg.eclipse.jdt.internal.compiler.classfmt.ElementValuePairInfo; 1043: 1 16 [Lorg.eclipse.jdt.internal.compiler.lookup.AnnotationBinding; 1044: 1 16 [Lorg.eclipse.jdt.internal.compiler.lookup.ElementValuePair; 1045: 1 16 [Lorg.eclipse.jdt.internal.compiler.lookup.TypeVariableBinding; 1046: 1 16 ConditionEvaluator10f8ea15999f425494040ef51fb0d217 1047: 1 16 ConditionEvaluator21d28af04cf74bfc87c007b806ddc2a1 1048: 1 16 ConditionEvaluator3c011ed3a0b042c0bd61c82573aac5db 1049: 1 16 ConditionEvaluator45f23d5af2d344da8b5ded591b4f84ca 1050: 1 16 ConditionEvaluator5957f3f8704b451fb121ede5f5d9264a 1051: 1 16 ConditionEvaluator988f236291194cefa1eecbfdf300133d 1052: 1 16 ConditionEvaluatorf6223b8bf6ca404ca7089e1a099d6ad7 1053: 1 16 com.intellij.rt.execution.application.AppMain$1 1054: 1 16 com.sample.Rule_GroupSOs_IOPExists_NotFinished_ASAP_1143440146DefaultConsequenceInvoker 1055: 1 16 com.sample.Rule_GroupSOs_IOPExists_NotFinished_ASAP_1143440146Predicate0Invoker 1056: 1 16 com.sample.Rule_GroupSOs_IOPExists_NotFinished_ASAP_1143440146Predicate0InvokerGenerated 1057: 1 16 com.sample.Rule_GroupSOs_IOPExists_NotFinished_ASAP_1143440146Predicate1Invoker 1058: 1 16 com.sample.Rule_GroupSOs_IOPExists_NotFinished_ASAP_1143440146Predicate1InvokerGenerated 1059: 1 16 com.sample.Rule_GroupSOs_NoIOP_AddrMismatch911570505DefaultConsequenceInvoker 1060: 1 16 com.sample.Rule_GroupSOs_NoIOP_AddrMismatch911570505DefaultConsequenceInvokerGenerated 1061: 1 16 com.sample.Rule_GroupSOs_NoIOP_AddrMismatch911570505Predicate0Invoker 1062: 1 16 com.sample.Rule_GroupSOs_NoIOP_AddrMismatch911570505Predicate0InvokerGenerated 1063: 1 16 com.sample.Rule_GroupSOs_NoProductType1631874407DefaultConsequenceInvoker 1064: 1 16 com.sample.SMDebugAgendaEventListener 1065: 1 16 com.sample.SMDebugWorkingMemoryEventListener 1066: 1 16 com.sun.beans.WeakCache 1067: 1 16 com.sun.naming.internal.VersionHelper12 1068: 1 16 com.sun.org.apache.xerces.internal.dom.CharacterDataImpl$1 1069: 1 16 com.sun.org.apache.xerces.internal.impl.dv.dtd.IDDatatypeValidator 1070: 1 16 com.sun.org.apache.xerces.internal.impl.dv.dtd.IDREFDatatypeValidator 1071: 1 16 com.sun.org.apache.xerces.internal.impl.dv.dtd.NMTOKENDatatypeValidator 1072: 1 16 com.sun.org.apache.xerces.internal.impl.dv.dtd.NOTATIONDatatypeValidator 1073: 1 16 com.sun.org.apache.xerces.internal.impl.dv.dtd.StringDatatypeValidator 1074: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.AnyAtomicDV 1075: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.AnySimpleDV 1076: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.AnyURIDV 1077: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.Base64BinaryDV 1078: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.BooleanDV 1079: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DateDV 1080: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DateTimeDV 1081: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DayDV 1082: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DayTimeDurationDV 1083: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DecimalDV 1084: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DoubleDV 1085: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.DurationDV 1086: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.EntityDV 1087: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.FloatDV 1088: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.HexBinaryDV 1089: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.IDDV 1090: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.IDREFDV 1091: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.IntegerDV 1092: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.ListDV 1093: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.MonthDV 1094: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.MonthDayDV 1095: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.PrecisionDecimalDV 1096: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.StringDV 1097: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.TimeDV 1098: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.UnionDV 1099: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDecl$1 1100: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.XSSimpleTypeDecl$4 1101: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.YearDV 1102: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.YearMonthDV 1103: 1 16 com.sun.org.apache.xerces.internal.impl.dv.xs.YearMonthDurationDV 1104: 1 16 com.sun.org.apache.xerces.internal.impl.xs.XSConstraints$1 1105: 1 16 com.sun.org.apache.xerces.internal.impl.xs.models.XSEmptyCM 1106: 1 16 com.sun.org.apache.xerces.internal.impl.xs.util.XIntPool 1107: 1 16 com.sun.org.apache.xerces.internal.impl.xs.util.XSObjectListImpl$1 1108: 1 16 com.sun.org.apache.xerces.internal.jaxp.validation.DraconianErrorHandler 1109: 1 16 com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory$XMLGrammarPoolWrapper 1110: 1 16 com.sun.org.apache.xerces.internal.util.AugmentationsImpl 1111: 1 16 com.sun.org.apache.xerces.internal.util.DOMEntityResolverWrapper 1112: 1 16 com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper 1113: 1 16 com.sun.org.apache.xerces.internal.utils.SecuritySupport 1114: 1 16 com.thoughtworks.xstream.XStream$1 1115: 1 16 com.thoughtworks.xstream.XStream$2 1116: 1 16 com.thoughtworks.xstream.converters.basic.BigDecimalConverter 1117: 1 16 com.thoughtworks.xstream.converters.basic.BigIntegerConverter 1118: 1 16 com.thoughtworks.xstream.converters.basic.CharConverter 1119: 1 16 com.thoughtworks.xstream.converters.basic.DoubleConverter 1120: 1 16 com.thoughtworks.xstream.converters.basic.FloatConverter 1121: 1 16 com.thoughtworks.xstream.converters.basic.IntConverter 1122: 1 16 com.thoughtworks.xstream.converters.basic.LongConverter 1123: 1 16 com.thoughtworks.xstream.converters.basic.NullConverter 1124: 1 16 com.thoughtworks.xstream.converters.basic.ShortConverter 1125: 1 16 com.thoughtworks.xstream.converters.basic.StringBufferConverter 1126: 1 16 com.thoughtworks.xstream.converters.basic.StringBuilderConverter 1127: 1 16 com.thoughtworks.xstream.converters.basic.URIConverter 1128: 1 16 com.thoughtworks.xstream.converters.basic.URLConverter 1129: 1 16 com.thoughtworks.xstream.converters.basic.UUIDConverter 1130: 1 16 com.thoughtworks.xstream.converters.collections.ArrayConverter 1131: 1 16 com.thoughtworks.xstream.converters.collections.BitSetConverter 1132: 1 16 com.thoughtworks.xstream.converters.collections.CharArrayConverter 1133: 1 16 com.thoughtworks.xstream.converters.collections.PropertiesConverter 1134: 1 16 com.thoughtworks.xstream.converters.collections.TreeMapConverter$NullComparator 1135: 1 16 com.thoughtworks.xstream.converters.enums.EnumConverter 1136: 1 16 com.thoughtworks.xstream.converters.enums.EnumSetConverter 1137: 1 16 com.thoughtworks.xstream.converters.extended.CharsetConverter 1138: 1 16 com.thoughtworks.xstream.converters.extended.ColorConverter 1139: 1 16 com.thoughtworks.xstream.converters.extended.CurrencyConverter 1140: 1 16 com.thoughtworks.xstream.converters.extended.DurationConverter 1141: 1 16 com.thoughtworks.xstream.converters.extended.DynamicProxyConverter$1 1142: 1 16 com.thoughtworks.xstream.converters.extended.EncodedByteArrayConverter 1143: 1 16 com.thoughtworks.xstream.converters.extended.FileConverter 1144: 1 16 com.thoughtworks.xstream.converters.extended.GregorianCalendarConverter 1145: 1 16 com.thoughtworks.xstream.converters.extended.JavaMethodConverter 1146: 1 16 com.thoughtworks.xstream.converters.extended.LocaleConverter 1147: 1 16 com.thoughtworks.xstream.converters.extended.RegexPatternConverter 1148: 1 16 com.thoughtworks.xstream.converters.extended.SqlDateConverter 1149: 1 16 com.thoughtworks.xstream.converters.extended.SqlTimeConverter 1150: 1 16 com.thoughtworks.xstream.converters.extended.SqlTimestampConverter 1151: 1 16 com.thoughtworks.xstream.converters.extended.StackTraceElementConverter 1152: 1 16 com.thoughtworks.xstream.converters.extended.StackTraceElementFactory15 1153: 1 16 com.thoughtworks.xstream.converters.extended.SubjectConverter 1154: 1 16 com.thoughtworks.xstream.converters.reflection.ImmutableFieldKeySorter 1155: 1 16 com.thoughtworks.xstream.converters.reflection.SerializableConverter$UnserializableParentsReflectionProvider 1156: 1 16 com.thoughtworks.xstream.core.ClassLoaderReference 1157: 1 16 com.thoughtworks.xstream.core.JVM 1158: 1 16 com.thoughtworks.xstream.core.ReferenceByXPathMarshallingStrategy 1159: 1 16 com.thoughtworks.xstream.core.util.Base64Encoder 1160: 1 16 com.thoughtworks.xstream.mapper.ArrayMapper 1161: 1 16 com.thoughtworks.xstream.mapper.PackageAliasingMapper$1 1162: 1 16 com.thoughtworks.xstream.security.AnyTypePermission 1163: 1 16 com.thoughtworks.xstream.security.NoTypePermission 1164: 1 16 java.io.FileDescriptor$1 1165: 1 16 java.lang.CharacterDataLatin1 1166: 1 16 java.lang.InheritableThreadLocal 1167: 1 16 java.lang.Runtime 1168: 1 16 java.lang.String$CaseInsensitiveComparator 1169: 1 16 java.lang.System$2 1170: 1 16 java.lang.Terminator$1 1171: 1 16 java.lang.invoke.MemberName$Factory 1172: 1 16 java.lang.ref.Reference$Lock 1173: 1 16 java.lang.reflect.ReflectAccess 1174: 1 16 java.net.InetAddress$2 1175: 1 16 java.net.URLClassLoader$7 1176: 1 16 java.nio.Bits$1 1177: 1 16 java.nio.charset.CoderResult$1 1178: 1 16 java.nio.charset.CoderResult$2 1179: 1 16 java.security.ProtectionDomain$1 1180: 1 16 java.security.ProtectionDomain$3 1181: 1 16 java.text.MessageFormat$Field 1182: 1 16 java.util.Collections$EmptyEnumeration 1183: 1 16 java.util.Collections$EmptyIterator 1184: 1 16 java.util.Collections$EmptyList 1185: 1 16 java.util.Collections$EmptySet 1186: 1 16 java.util.Collections$UnmodifiableSet 1187: 1 16 java.util.Currency$CurrencyNameGetter 1188: 1 16 java.util.EnumMap$1 1189: 1 16 java.util.Hashtable$EntrySet 1190: 1 16 java.util.Hashtable$KeySet 1191: 1 16 java.util.ResourceBundle$Control 1192: 1 16 java.util.TreeMap$KeySet 1193: 1 16 java.util.TreeSet 1194: 1 16 java.util.concurrent.ThreadPoolExecutor$AbortPolicy 1195: 1 16 java.util.concurrent.atomic.AtomicReferenceArray 1196: 1 16 java.util.jar.JavaUtilJarAccessImpl 1197: 1 16 java.util.regex.Pattern$4 1198: 1 16 java.util.regex.Pattern$CharPropertyNames$10 1199: 1 16 java.util.regex.Pattern$CharPropertyNames$11 1200: 1 16 java.util.regex.Pattern$CharPropertyNames$12 1201: 1 16 java.util.regex.Pattern$CharPropertyNames$13 1202: 1 16 java.util.regex.Pattern$CharPropertyNames$14 1203: 1 16 java.util.regex.Pattern$CharPropertyNames$15 1204: 1 16 java.util.regex.Pattern$CharPropertyNames$16 1205: 1 16 java.util.regex.Pattern$CharPropertyNames$17 1206: 1 16 java.util.regex.Pattern$CharPropertyNames$18 1207: 1 16 java.util.regex.Pattern$CharPropertyNames$19 1208: 1 16 java.util.regex.Pattern$CharPropertyNames$20 1209: 1 16 java.util.regex.Pattern$CharPropertyNames$21 1210: 1 16 java.util.regex.Pattern$CharPropertyNames$22 1211: 1 16 java.util.regex.Pattern$CharPropertyNames$23 1212: 1 16 java.util.regex.Pattern$CharPropertyNames$5 1213: 1 16 java.util.regex.Pattern$CharPropertyNames$6 1214: 1 16 java.util.regex.Pattern$CharPropertyNames$7 1215: 1 16 java.util.regex.Pattern$CharPropertyNames$8 1216: 1 16 java.util.regex.Pattern$CharPropertyNames$9 1217: 1 16 java.util.regex.Pattern$LastNode 1218: 1 16 java.util.regex.Pattern$Node 1219: 1 16 java.util.zip.ZipFile$1 1220: 1 16 javax.xml.datatype.SecuritySupport 1221: 1 16 javax.xml.parsers.SecuritySupport 1222: 1 16 org.drools.compiler.builder.impl.ClassDefinitionFactory 1223: 1 16 org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$1 1224: 1 16 org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$2 1225: 1 16 org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$3 1226: 1 16 org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$4 1227: 1 16 org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$5 1228: 1 16 org.drools.compiler.builder.impl.DeclaredClassBuilder 1229: 1 16 org.drools.compiler.builder.impl.KnowledgeBuilderFactoryServiceImpl 1230: 1 16 org.drools.compiler.builder.impl.TypeDeclarationFactory 1231: 1 16 org.drools.compiler.builder.impl.TypeDeclarationNameResolver 1232: 1 16 org.drools.compiler.commons.jci.compilers.JavaCompilerFactory 1233: 1 16 org.drools.compiler.kie.builder.impl.KieRepositoryImpl$DummyKieScanner 1234: 1 16 org.drools.compiler.kie.util.CDIHelper$ReflectionBeanCreator 1235: 1 16 org.drools.compiler.kproject.models.KieBaseModelImpl$KBaseConverter 1236: 1 16 org.drools.compiler.kproject.models.KieModuleModelImpl$kModuleConverter 1237: 1 16 org.drools.compiler.kproject.models.KieModuleModelImpl$kModuleMarshaller 1238: 1 16 org.drools.compiler.kproject.models.KieSessionModelImpl$KSessionConverter 1239: 1 16 org.drools.compiler.kproject.models.ListenerModelImpl$ListenerConverter 1240: 1 16 org.drools.compiler.kproject.models.QualifierModelImpl$QualifierConverter 1241: 1 16 org.drools.compiler.kproject.models.WorkItemHandlerModelImpl$WorkItemHandelerConverter 1242: 1 16 org.drools.compiler.rule.builder.MVELConstraintBuilder 1243: 1 16 org.drools.compiler.rule.builder.MVELConstraintBuilder$1 1244: 1 16 org.drools.compiler.rule.builder.MVELConstraintBuilder$BooleanConversionHandler 1245: 1 16 org.drools.compiler.rule.builder.MVELConstraintBuilder$StringCoercionCompatibilityEvaluator 1246: 1 16 org.drools.compiler.rule.builder.RuleBuilder 1247: 1 16 org.drools.compiler.rule.builder.dialect.asm.ASMConsequenceStubBuilder 1248: 1 16 org.drools.compiler.rule.builder.dialect.asm.ASMEvalStubBuilder 1249: 1 16 org.drools.compiler.rule.builder.dialect.asm.ASMPredicateStubBuilder 1250: 1 16 org.drools.compiler.rule.builder.dialect.asm.ASMReturnValueStubBuilder 1251: 1 16 org.drools.compiler.rule.builder.dialect.java.JavaAccumulateBuilder 1252: 1 16 org.drools.compiler.rule.builder.dialect.java.JavaExprAnalyzer 1253: 1 16 org.drools.compiler.rule.builder.dialect.java.JavaRuleClassBuilder 1254: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$1 1255: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$10 1256: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$11 1257: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$2 1258: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$3 1259: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$4 1260: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$5 1261: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$6 1262: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$7 1263: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$8 1264: 1 16 org.drools.compiler.rule.builder.dialect.java.KnowledgeHelperFixer$9 1265: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELAccumulateBuilder 1266: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder 1267: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$1 1268: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$10 1269: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$11 1270: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$2 1271: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$3 1272: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$4 1273: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$5 1274: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$6 1275: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$7 1276: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$8 1277: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELConsequenceBuilder$9 1278: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELEvalBuilder 1279: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELExprAnalyzer 1280: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELPredicateBuilder 1281: 1 16 org.drools.compiler.rule.builder.dialect.mvel.MVELReturnValueBuilder 1282: 1 16 org.drools.core.RuleActivationListenerFactory 1283: 1 16 org.drools.core.base.CalendarsImpl 1284: 1 16 org.drools.core.base.ClassFieldAccessorFactory 1285: 1 16 org.drools.core.base.FieldFactory 1286: 1 16 org.drools.core.base.SalienceInteger 1287: 1 16 org.drools.core.base.TypeResolver$AcceptAllClassFilter 1288: 1 16 org.drools.core.base.TypeResolver$ExcludeAnnotationClassFilter 1289: 1 16 org.drools.core.base.TypeResolver$OnlyAnnotationClassFilter 1290: 1 16 org.drools.core.base.accumulators.CollectAccumulator$CollectContext 1291: 1 16 org.drools.core.base.evaluators.IsAEvaluatorDefinition 1292: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$BooleanArrayContainsEvaluator 1293: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ByteArrayContainsEvaluator 1294: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$CharArrayContainsEvaluator 1295: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$DoubleArrayContainsEvaluator 1296: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$FloatArrayContainsEvaluator 1297: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$IntegerArrayContainsEvaluator 1298: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$LongArrayContainsEvaluator 1299: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ObjectArrayContainsEvaluator 1300: 1 16 org.drools.core.base.evaluators.SetEvaluatorsDefinition$ShortArrayContainsEvaluator 1301: 1 16 org.drools.core.base.evaluators.StrEvaluatorDefinition 1302: 1 16 org.drools.core.base.mvel.MVELCalendarCoercion 1303: 1 16 org.drools.core.base.mvel.MVELCompilationUnit$InterceptorMap 1304: 1 16 org.drools.core.base.mvel.MVELDateCoercion 1305: 1 16 org.drools.core.base.mvel.MVELDebugHandler$MVELDebugger 1306: 1 16 org.drools.core.common.EmptyBetaConstraints 1307: 1 16 org.drools.core.common.IdentityAssertMapComparator 1308: 1 16 org.drools.core.common.PriorityQueueAgendaGroupFactory 1309: 1 16 org.drools.core.concurrent.ExecutorProviderImpl 1310: 1 16 org.drools.core.concurrent.ExecutorProviderImpl$DaemonThreadFactory 1311: 1 16 org.drools.core.conflict.DepthConflictResolver 1312: 1 16 org.drools.core.event.AgendaEventSupport 1313: 1 16 org.drools.core.event.RuleEventListenerSupport 1314: 1 16 org.drools.core.event.RuleRuntimeEventSupport 1315: 1 16 org.drools.core.impl.KnowledgeBaseFactoryServiceImpl 1316: 1 16 org.drools.core.io.impl.ResourceFactoryServiceImpl 1317: 1 16 org.drools.core.marshalling.impl.ClassObjectMarshallingStrategyAcceptor 1318: 1 16 org.drools.core.phreak.PhreakAccumulateNode 1319: 1 16 org.drools.core.phreak.PhreakBranchNode 1320: 1 16 org.drools.core.phreak.PhreakEvalNode 1321: 1 16 org.drools.core.phreak.PhreakExistsNode 1322: 1 16 org.drools.core.phreak.PhreakFromNode 1323: 1 16 org.drools.core.phreak.PhreakJoinNode 1324: 1 16 org.drools.core.phreak.PhreakNotNode 1325: 1 16 org.drools.core.phreak.PhreakQueryNode 1326: 1 16 org.drools.core.phreak.PhreakQueryTerminalNode 1327: 1 16 org.drools.core.phreak.PhreakRuleTerminalNode 1328: 1 16 org.drools.core.phreak.PhreakTimerNode 1329: 1 16 org.drools.core.phreak.RuleExecutor$SalienceComparator 1330: 1 16 org.drools.core.phreak.RuleNetworkEvaluator 1331: 1 16 org.drools.core.reteoo.ClassObjectTypeConf$ObjectTypeNodeComparator 1332: 1 16 org.drools.core.reteoo.EmptyLeftTupleSinkAdapter 1333: 1 16 org.drools.core.reteoo.EmptyObjectSinkAdapter 1334: 1 16 org.drools.core.reteoo.InitialFactImpl 1335: 1 16 org.drools.core.reteoo.ObjectTypeNode$ExpireJob 1336: 1 16 org.drools.core.reteoo.RuleTerminalNode$SortDeclarations 1337: 1 16 org.drools.core.reteoo.SegmentMemory$AccumulateMemoryPrototype 1338: 1 16 org.drools.core.reteoo.builder.BuildUtils 1339: 1 16 org.drools.core.reteoo.builder.CollectBuilder 1340: 1 16 org.drools.core.reteoo.builder.ConditionalBranchBuilder 1341: 1 16 org.drools.core.reteoo.builder.EntryPointBuilder 1342: 1 16 org.drools.core.reteoo.builder.EvalBuilder 1343: 1 16 org.drools.core.reteoo.builder.ForallBuilder 1344: 1 16 org.drools.core.reteoo.builder.FromBuilder 1345: 1 16 org.drools.core.reteoo.builder.GroupElementBuilder 1346: 1 16 org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder 1347: 1 16 org.drools.core.reteoo.builder.GroupElementBuilder$ExistsBuilder 1348: 1 16 org.drools.core.reteoo.builder.GroupElementBuilder$NotBuilder 1349: 1 16 org.drools.core.reteoo.builder.GroupElementBuilder$OrBuilder 1350: 1 16 org.drools.core.reteoo.builder.NamedConsequenceBuilder 1351: 1 16 org.drools.core.reteoo.builder.PatternBuilder 1352: 1 16 org.drools.core.reteoo.builder.QueryElementBuilder 1353: 1 16 org.drools.core.reteoo.builder.ReteooRuleBuilder 1354: 1 16 org.drools.core.reteoo.builder.TimerBuilder 1355: 1 16 org.drools.core.reteoo.builder.WindowReferenceBuilder 1356: 1 16 org.drools.core.rule.EntryPointId 1357: 1 16 org.drools.core.rule.LogicTransformer 1358: 1 16 org.drools.core.rule.LogicTransformer$AndOrTransformation 1359: 1 16 org.drools.core.rule.LogicTransformer$ExistOrTransformation 1360: 1 16 org.drools.core.rule.LogicTransformer$NotOrTransformation 1361: 1 16 org.drools.core.rule.constraint.MvelConstraint$PlainIndexEvaluator 1362: 1 16 org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler 1363: 1 16 org.drools.core.time.impl.DefaultTimerJobFactoryManager 1364: 1 16 org.drools.core.type.DateFormatsImpl$1 1365: 1 16 org.drools.core.type.DateFormatsImpl$2 1366: 1 16 org.drools.core.util.AbstractHashTable$EqualityEquals 1367: 1 16 org.drools.core.util.LinkedList$LinkedListFastIterator 1368: 1 16 org.drools.core.util.MVELSafeHelper$RawMVELEvaluator 1369: 1 16 org.drools.core.util.MemoryUtil$MemoryStats 1370: 1 16 org.drools.core.util.Predicate$PassAll 1371: 1 16 org.drools.core.util.bitmask.AllSetBitMask 1372: 1 16 org.drools.core.util.bitmask.AllSetButLastBitMask 1373: 1 16 org.drools.core.util.bitmask.EmptyBitMask 1374: 1 16 org.eclipse.jdt.internal.compiler.CompilationResult$1 1375: 1 16 org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration$1 1376: 1 16 org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$2 1377: 1 16 org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding$3 1378: 1 16 org.kie.api.runtime.conf.BeliefSystemTypeOption 1379: 1 16 org.kie.api.runtime.conf.ClockTypeOption 1380: 1 16 org.kie.api.runtime.conf.TimedRuleExectionOption$1 1381: 1 16 org.kie.internal.assembler.KieAssemblersImpl 1382: 1 16 org.kie.internal.conf.ConsequenceExceptionHandlerOption 1383: 1 16 org.kie.internal.runtime.KieRuntimesImpl 1384: 1 16 org.kie.internal.runtime.conf.ForceEagerActivationOption$1 1385: 1 16 org.kie.internal.runtime.conf.ForceEagerActivationOption$2 1386: 1 16 org.kie.internal.weaver.KieWeaversImpl 1387: 1 16 org.mvel2.compiler.BlankLiteral 1388: 1 16 org.mvel2.conversion.BigDecimalCH 1389: 1 16 org.mvel2.conversion.BigDecimalCH$1 1390: 1 16 org.mvel2.conversion.BigDecimalCH$10 1391: 1 16 org.mvel2.conversion.BigDecimalCH$11 1392: 1 16 org.mvel2.conversion.BigDecimalCH$2 1393: 1 16 org.mvel2.conversion.BigDecimalCH$3 1394: 1 16 org.mvel2.conversion.BigDecimalCH$5 1395: 1 16 org.mvel2.conversion.BigDecimalCH$6 1396: 1 16 org.mvel2.conversion.BigDecimalCH$7 1397: 1 16 org.mvel2.conversion.BigDecimalCH$8 1398: 1 16 org.mvel2.conversion.BigDecimalCH$9 1399: 1 16 org.mvel2.conversion.BigIntegerCH 1400: 1 16 org.mvel2.conversion.BigIntegerCH$1 1401: 1 16 org.mvel2.conversion.BigIntegerCH$2 1402: 1 16 org.mvel2.conversion.BigIntegerCH$3 1403: 1 16 org.mvel2.conversion.BigIntegerCH$5 1404: 1 16 org.mvel2.conversion.BigIntegerCH$6 1405: 1 16 org.mvel2.conversion.BigIntegerCH$7 1406: 1 16 org.mvel2.conversion.BigIntegerCH$8 1407: 1 16 org.mvel2.conversion.BigIntegerCH$9 1408: 1 16 org.mvel2.conversion.BooleanCH$1 1409: 1 16 org.mvel2.conversion.BooleanCH$10 1410: 1 16 org.mvel2.conversion.BooleanCH$2 1411: 1 16 org.mvel2.conversion.BooleanCH$3 1412: 1 16 org.mvel2.conversion.BooleanCH$4 1413: 1 16 org.mvel2.conversion.BooleanCH$5 1414: 1 16 org.mvel2.conversion.BooleanCH$6 1415: 1 16 org.mvel2.conversion.BooleanCH$7 1416: 1 16 org.mvel2.conversion.BooleanCH$8 1417: 1 16 org.mvel2.conversion.BooleanCH$9 1418: 1 16 org.mvel2.conversion.ByteCH 1419: 1 16 org.mvel2.conversion.ByteCH$1 1420: 1 16 org.mvel2.conversion.ByteCH$2 1421: 1 16 org.mvel2.conversion.ByteCH$3 1422: 1 16 org.mvel2.conversion.ByteCH$4 1423: 1 16 org.mvel2.conversion.ByteCH$5 1424: 1 16 org.mvel2.conversion.ByteCH$6 1425: 1 16 org.mvel2.conversion.ByteCH$7 1426: 1 16 org.mvel2.conversion.ByteCH$8 1427: 1 16 org.mvel2.conversion.CharArrayCH 1428: 1 16 org.mvel2.conversion.CharArrayCH$1 1429: 1 16 org.mvel2.conversion.CharCH 1430: 1 16 org.mvel2.conversion.CharCH$1 1431: 1 16 org.mvel2.conversion.CharCH$2 1432: 1 16 org.mvel2.conversion.CharCH$3 1433: 1 16 org.mvel2.conversion.CharCH$4 1434: 1 16 org.mvel2.conversion.CharCH$5 1435: 1 16 org.mvel2.conversion.CompositeCH 1436: 1 16 org.mvel2.conversion.DoubleCH 1437: 1 16 org.mvel2.conversion.DoubleCH$1 1438: 1 16 org.mvel2.conversion.DoubleCH$10 1439: 1 16 org.mvel2.conversion.DoubleCH$2 1440: 1 16 org.mvel2.conversion.DoubleCH$3 1441: 1 16 org.mvel2.conversion.DoubleCH$4 1442: 1 16 org.mvel2.conversion.DoubleCH$5 1443: 1 16 org.mvel2.conversion.DoubleCH$6 1444: 1 16 org.mvel2.conversion.DoubleCH$7 1445: 1 16 org.mvel2.conversion.DoubleCH$8 1446: 1 16 org.mvel2.conversion.DoubleCH$9 1447: 1 16 org.mvel2.conversion.FloatCH 1448: 1 16 org.mvel2.conversion.FloatCH$1 1449: 1 16 org.mvel2.conversion.FloatCH$10 1450: 1 16 org.mvel2.conversion.FloatCH$2 1451: 1 16 org.mvel2.conversion.FloatCH$3 1452: 1 16 org.mvel2.conversion.FloatCH$4 1453: 1 16 org.mvel2.conversion.FloatCH$5 1454: 1 16 org.mvel2.conversion.FloatCH$6 1455: 1 16 org.mvel2.conversion.FloatCH$7 1456: 1 16 org.mvel2.conversion.FloatCH$8 1457: 1 16 org.mvel2.conversion.FloatCH$9 1458: 1 16 org.mvel2.conversion.IntArrayCH 1459: 1 16 org.mvel2.conversion.IntArrayCH$1 1460: 1 16 org.mvel2.conversion.IntArrayCH$2 1461: 1 16 org.mvel2.conversion.IntegerCH 1462: 1 16 org.mvel2.conversion.IntegerCH$1 1463: 1 16 org.mvel2.conversion.IntegerCH$10 1464: 1 16 org.mvel2.conversion.IntegerCH$11 1465: 1 16 org.mvel2.conversion.IntegerCH$2 1466: 1 16 org.mvel2.conversion.IntegerCH$3 1467: 1 16 org.mvel2.conversion.IntegerCH$4 1468: 1 16 org.mvel2.conversion.IntegerCH$5 1469: 1 16 org.mvel2.conversion.IntegerCH$6 1470: 1 16 org.mvel2.conversion.IntegerCH$7 1471: 1 16 org.mvel2.conversion.IntegerCH$8 1472: 1 16 org.mvel2.conversion.IntegerCH$9 1473: 1 16 org.mvel2.conversion.ListCH 1474: 1 16 org.mvel2.conversion.LongCH 1475: 1 16 org.mvel2.conversion.LongCH$1 1476: 1 16 org.mvel2.conversion.LongCH$10 1477: 1 16 org.mvel2.conversion.LongCH$2 1478: 1 16 org.mvel2.conversion.LongCH$3 1479: 1 16 org.mvel2.conversion.LongCH$4 1480: 1 16 org.mvel2.conversion.LongCH$5 1481: 1 16 org.mvel2.conversion.LongCH$6 1482: 1 16 org.mvel2.conversion.LongCH$7 1483: 1 16 org.mvel2.conversion.LongCH$8 1484: 1 16 org.mvel2.conversion.LongCH$9 1485: 1 16 org.mvel2.conversion.ObjectCH 1486: 1 16 org.mvel2.conversion.SetCH 1487: 1 16 org.mvel2.conversion.ShortCH 1488: 1 16 org.mvel2.conversion.ShortCH$1 1489: 1 16 org.mvel2.conversion.ShortCH$10 1490: 1 16 org.mvel2.conversion.ShortCH$2 1491: 1 16 org.mvel2.conversion.ShortCH$3 1492: 1 16 org.mvel2.conversion.ShortCH$4 1493: 1 16 org.mvel2.conversion.ShortCH$5 1494: 1 16 org.mvel2.conversion.ShortCH$6 1495: 1 16 org.mvel2.conversion.ShortCH$7 1496: 1 16 org.mvel2.conversion.ShortCH$8 1497: 1 16 org.mvel2.conversion.ShortCH$9 1498: 1 16 org.mvel2.conversion.StringArrayCH 1499: 1 16 org.mvel2.conversion.StringArrayCH$1 1500: 1 16 org.mvel2.conversion.StringCH 1501: 1 16 org.slf4j.helpers.NOPLogger 1502: 1 16 org.slf4j.helpers.NOPLoggerFactory 1503: 1 16 org.slf4j.helpers.SubstituteLoggerFactory 1504: 1 16 sun.jvmstat.monitor.HostIdentifier 1505: 1 16 sun.jvmstat.perfdata.monitor.protocol.local.LocalVmManager$1 1506: 1 16 sun.jvmstat.perfdata.monitor.protocol.local.LocalVmManager$2 1507: 1 16 sun.jvmstat.perfdata.monitor.protocol.local.LocalVmManager$3 1508: 1 16 sun.misc.ASCIICaseInsensitiveComparator 1509: 1 16 sun.misc.FloatingDecimal$1 1510: 1 16 sun.misc.Launcher 1511: 1 16 sun.misc.Launcher$Factory 1512: 1 16 sun.misc.Perf 1513: 1 16 sun.misc.Unsafe 1514: 1 16 sun.net.DefaultProgressMeteringPolicy 1515: 1 16 sun.net.www.protocol.file.Handler 1516: 1 16 sun.net.www.protocol.jar.JarFileFactory 1517: 1 16 sun.reflect.GeneratedConstructorAccessor1 1518: 1 16 sun.reflect.GeneratedConstructorAccessor2 1519: 1 16 sun.reflect.GeneratedConstructorAccessor3 1520: 1 16 sun.reflect.GeneratedMethodAccessor1 1521: 1 16 sun.reflect.GeneratedMethodAccessor2 1522: 1 16 sun.reflect.GeneratedMethodAccessor3 1523: 1 16 sun.reflect.GeneratedMethodAccessor4 1524: 1 16 sun.reflect.GeneratedMethodAccessor5 1525: 1 16 sun.reflect.GeneratedMethodAccessor6 1526: 1 16 sun.reflect.ReflectionFactory 1527: 1 16 sun.security.provider.NativePRNG 1528: 1 16 sun.tools.attach.LinuxAttachProvider 1529: 1 16 sun.util.calendar.Gregorian 1530: 1 16 sun.util.calendar.JulianCalendar 1531: 1 16 sun.util.locale.InternalLocaleBuilder$CaseInsensitiveChar 1532: 1 16 sun.util.locale.provider.AuxLocaleProviderAdapter$NullProvider 1533: 1 16 sun.util.locale.provider.CalendarDataUtility$CalendarWeekParameterGetter 1534: 1 16 sun.util.locale.provider.SPILocaleProviderAdapter 1535: 1 16 sun.util.locale.provider.TimeZoneNameUtility$TimeZoneNameGetter 1536: 1 16 sun.util.resources.LocaleData 1537: 1 16 sun.util.resources.LocaleData$LocaleDataResourceBundleControl Total 82225 12605296 Drools / [Bug] DROOLS-647 memory leak Change By: Mario Fusco Status: Open Resolved Fix Version/s: 6.2.0.CR3 Resolution: Cannot Reproduce Bug [Add Comment] Add Comment This message was sent by Atlassian JIRA (v6.3.8#6338-sha1:68f19fa) [Atlassian logo] > memory leak > ----------- > > Key: DROOLS-647 > URL: https://issues.jboss.org/browse/DROOLS-647 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Reporter: Dawna Floyd > Assignee: Mario Fusco > Fix For: 6.2.0.CR3 > > Attachments: DROOL_TEST.zip > > > references to fact handles not being removed when objects are removed from memory. Converted our application from 5.0.1 to 6.1_Final and encountered memory leaks in the drools processing. Found references to defect 498 and checked out the 6.1.1 code based and built the source (the download package doesn't seem to have these fixes). The majority of leaks were corrected with this code line, however there still remains a memory leak when we run our defined rules. Even though a rule never fires, it's evaluation seems to hold onto beta memory forever and the test application will eventually run out of memory. I can provide a test program that highlights the leak. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:42 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-260) Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-260: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab > ------------------------------------------------------------------------------------------ > > Key: WFCORE-260 > URL: https://issues.jboss.org/browse/WFCORE-260 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:42 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-259) Improve realm readiness handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-259: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Improve realm readiness handling > -------------------------------- > > Key: WFCORE-259 > URL: https://issues.jboss.org/browse/WFCORE-259 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > Currently we display an error message informing users that they need to add a new user if any of the authentication mechanisms within a realm report that they are not ready to handle requests. > The reason for this was so that if properties backed authentication we available along with local authentication then the local authentication would not prevent the prompt from being displayed. > However there could be additional mechanisms suitable for use with HTTP so we need a small modification to stop taking into account the local authentication mechanism but allow requests in if any of the other HTTP compatible mechanisms are ready to handle requests. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:42 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-257) Remove TODO comment saying we need access constraints for server-name and sasl-protocol for management. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-257: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Remove TODO comment saying we need access constraints for server-name and sasl-protocol for management. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-257 > URL: https://issues.jboss.org/browse/WFCORE-257 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Minor > Fix For: 1.0.0.Alpha14 > > > The management interfaces are already flagged as MANAGEMENT_INTERFACES so access is already restricted to all attributes, we don't need an additional access constraint. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:43 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-256) Remove comment from schema that says Kerberos is only possible for HTTP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-256: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Remove comment from schema that says Kerberos is only possible for HTTP > ----------------------------------------------------------------------- > > Key: WFCORE-256 > URL: https://issues.jboss.org/browse/WFCORE-256 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:43 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-253) Remoting subsystem sasl-protocol and server-name should support expressions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-253: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Remoting subsystem sasl-protocol and server-name should support expressions > --------------------------------------------------------------------------- > > Key: WFCORE-253 > URL: https://issues.jboss.org/browse/WFCORE-253 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:43 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-240) We need something similar to StandardConfigsXMLValidationUnitTestCase in Core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-240: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > We need something similar to StandardConfigsXMLValidationUnitTestCase in Core > ----------------------------------------------------------------------------- > > Key: WFCORE-240 > URL: https://issues.jboss.org/browse/WFCORE-240 > Project: WildFly Core > Issue Type: Feature Request > Components: Test Suite > Reporter: Darran Lofthouse > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha14 > > > One feature of this test is that it validates that schemas are correct according to the schema schema, presently we only find out about errors in schemas when the wildfly testsuite is executed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:43 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-228) standalone.bat very slow In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-228: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > standalone.bat very slow > ------------------------ > > Key: WFCORE-228 > URL: https://issues.jboss.org/browse/WFCORE-228 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Reporter: Philippe Marschall > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha14 > > > With a plain WildFly AS downloaded and executing {code}standalone.bat{code} we see about two to three seconds spent in this loop: > {code} > rem Setup directories, note directories with spaces do not work > set "CONSOLIDATED_OPTS=%JAVA_OPTS% %SERVER_OPTS%" > :DIRLOOP > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.base.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_BASE_DIR=%%~fi" > ) > ) > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.config.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_CONFIG_DIR=%%~fi" > ) > ) > echo(%CONSOLIDATED_OPTS% | findstr /r /c:"^-Djboss.server.log.dir" > nul && ( > for /f "tokens=1,2* delims==" %%a IN ("%CONSOLIDATED_OPTS%") DO ( > for /f %%i IN ("%%b") DO set "JBOSS_LOG_DIR=%%~fi" > ) > ) > for /f "tokens=1* delims= " %%i IN ("%CONSOLIDATED_OPTS%") DO ( > if %%i == "" ( > goto ENDDIRLOOP > ) else ( > set CONSOLIDATED_OPTS=%%j > GOTO DIRLOOP > ) > ) > :ENDDIRLOOP > {code} > It does not seem to define any variables by default, simply removing the code noticeably reduces start up time. > Windows 7, 64 bit, SSD -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:44 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-213: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14, 1.0.0.Beta1 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:44 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-137) Add Kerberos tests to domain-management module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-137: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Add Kerberos tests to domain-management module > ---------------------------------------------- > > Key: WFCORE-137 > URL: https://issues.jboss.org/browse/WFCORE-137 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:45 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-133) CLI -connect option throws full stacktrace exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-133: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > CLI -connect option throws full stacktrace exception > ---------------------------------------------------- > > Key: WFCORE-133 > URL: https://issues.jboss.org/browse/WFCORE-133 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha8 > Reporter: Joe Wertz > Assignee: Joe Wertz > Priority: Minor > Fix For: 1.0.0.Alpha14 > > > Full stacktrace is printed for exceptions that occur before the CLI connects to a server. > Instead, only the exception messages should be printed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:45 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-129) Overlay does not work for subunits in exploded deployments. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-129: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Overlay does not work for subunits in exploded deployments. > ----------------------------------------------------------- > > Key: WFCORE-129 > URL: https://issues.jboss.org/browse/WFCORE-129 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha8 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Alpha14 > > > If deployment is exploded and has subdeployments overlay wont work on files contained in said subdeployments. > Reproducers: https://github.com/baranowb/wildfly/tree/WFCORE-83-TESTS -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:45 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-107: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Update whoami operation to return authentication mechanism where verbose=true > ----------------------------------------------------------------------------- > > Key: WFCORE-107 > URL: https://issues.jboss.org/browse/WFCORE-107 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached. > This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:46 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-103) Add Full Kerberos Support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-103: ------------------------------- Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Add Full Kerberos Support > ------------------------- > > Key: WFCORE-103 > URL: https://issues.jboss.org/browse/WFCORE-103 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: management_security, > Fix For: 1.0.0.Alpha14 > > > There are a number of steps required to full add Kerberos support - this is a top level tracking task to be resolved once all steps are complete. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:46 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-80) Upgrade org.apache.httpcomponents:httpclient to 4.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-80: ------------------------------ Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Upgrade org.apache.httpcomponents:httpclient to 4.3.2 > ----------------------------------------------------- > > Key: WFCORE-80 > URL: https://issues.jboss.org/browse/WFCORE-80 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Affects Versions: 1.0.0.Alpha5 > Reporter: Jim Ma > Assignee: Jim Ma > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:46 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-54) Add Keycloak authentication/authorization to http management endpoint In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-54: ------------------------------ Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Add Keycloak authentication/authorization to http management endpoint > --------------------------------------------------------------------- > > Key: WFCORE-54 > URL: https://issues.jboss.org/browse/WFCORE-54 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Stan Silvert > Assignee: Stan Silvert > Fix For: 1.0.0.Alpha14 > > > This is here to track the core changes needed for WFLY-3591. See that jira for details. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:46 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-31) The JBoss Modules schemas are missing from the build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-31: ------------------------------ Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > The JBoss Modules schemas are missing from the build > ---------------------------------------------------- > > Key: WFCORE-31 > URL: https://issues.jboss.org/browse/WFCORE-31 > Project: WildFly Core > Issue Type: Bug > Reporter: Darran Lofthouse > Assignee: Eduardo Martins > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:47 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 08:54:47 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-25) Windows PowerShell scripts in bin In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFCORE-25: ------------------------------ Fix Version/s: 1.0.0.Alpha14 (was: 1.0.0.Alpha13) > Windows PowerShell scripts in bin > --------------------------------- > > Key: WFCORE-25 > URL: https://issues.jboss.org/browse/WFCORE-25 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha14 > > > Add .psh scripts that match the functionality of our .sh scripts. Leave the .bat scripts in their current limited-functionality form for people still on XP, but use PowerShell as the recommended Windows scripting language. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 08:54:47 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 08:54:47 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AS7-3050) RESTEasy: Boolean configuration parameters don't reject non-sense content In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-3050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020797#comment-13020797 ] RH Bugzilla Integration commented on AS7-3050: ---------------------------------------------- Marek Kopecky changed the Status of [bug 899664|https://bugzilla.redhat.com/show_bug.cgi?id=899664] from ON_QA to ASSIGNED > RESTEasy: Boolean configuration parameters don't reject non-sense content > ------------------------------------------------------------------------- > > Key: AS7-3050 > URL: https://issues.jboss.org/browse/AS7-3050 > Project: Application Server 7 > Issue Type: Bug > Components: REST > Affects Versions: 7.1.0.Beta1b > Reporter: Pavel Janousek > Assignee: Weinan Li > Fix For: Awaiting Volunteers > > > RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. These options which are type of Boolean (= true, false; maybe we should do support for 0 and 1 too), other invalid or non-sense setting should be rejected as invalid deployment description and a such application should not be deployed at all. > Affected options are: > - resteasy.scan > - resteasy.scan.providers > - resteasy.scan.resources > - resteasy.use.builtin.providers -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 09:04:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 18 Nov 2014 09:04:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-647) memory leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020802#comment-13020802 ] Mario Fusco commented on DROOLS-647: ------------------------------------ Yes, the fix is present on the 6.2.x branch. We are not planning to deploy a patch release of the 6.1.x so you'll have to use the 6.2.0 release to have this fix. You can already give a try to the 6.2.0.CR2 and check if this fixes your problem. The final release will be available in a few weeks. Mario > memory leak > ----------- > > Key: DROOLS-647 > URL: https://issues.jboss.org/browse/DROOLS-647 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Reporter: Dawna Floyd > Assignee: Mario Fusco > Fix For: 6.2.0.CR3 > > Attachments: DROOL_TEST.zip > > > references to fact handles not being removed when objects are removed from memory. Converted our application from 5.0.1 to 6.1_Final and encountered memory leaks in the drools processing. Found references to defect 498 and checked out the 6.1.1 code based and built the source (the download package doesn't seem to have these fixes). The majority of leaks were corrected with this code line, however there still remains a memory leak when we run our defined rules. Even though a rule never fires, it's evaluation seems to hold onto beta memory forever and the test application will eventually run out of memory. I can provide a test program that highlights the leak. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 09:20:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 18 Nov 2014 09:20:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-64) Implement SCRAM Server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd resolved ELY-64. ---------------------------- Assignee: David Lloyd Resolution: Done > Implement SCRAM Server > ---------------------- > > Key: ELY-64 > URL: https://issues.jboss.org/browse/ELY-64 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 09:27:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 09:27:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-184) Handle external requests during boot with a NoSuchResourceException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020814#comment-13020814 ] RH Bugzilla Integration commented on WFCORE-184: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1154121|https://bugzilla.redhat.com/show_bug.cgi?id=1154121] from ON_QA to VERIFIED > Handle external requests during boot with a NoSuchResourceException > ------------------------------------------------------------------- > > Key: WFCORE-184 > URL: https://issues.jboss.org/browse/WFCORE-184 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 1.0.0.Alpha11 > > > Lock out external callers during boot by immediately replying as if the root resource does not exist. > This will not break callers like the ARQ containers that poll in a loop waiting for the root 'server-state' attribute to be 'RUNNING' as those callers already need to have logic for dealing with the failures that can occur during those reads. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 09:29:40 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Tue, 18 Nov 2014 09:29:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1236) Race condition in SemaphoreConcurrentLinkedQueueManagedConnectionPool In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesper Pedersen updated JBJCA-1236: ----------------------------------- Fix Version/s: 1.0.30.Final 1.2.1.Final Affects Version/s: 1.0.29.Final > Race condition in SemaphoreConcurrentLinkedQueueManagedConnectionPool > --------------------------------------------------------------------- > > Key: JBJCA-1236 > URL: https://issues.jboss.org/browse/JBJCA-1236 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.29.Final, 1.2.0.Final > Reporter: John O'Hara > Assignee: Jesper Pedersen > Fix For: 1.0.30.Final, 1.2.1.Final > > > A race condition in the ConnectionListenerWrapper and incorrect logic when returning the ConnectionListener object to the ConcurrentLinkedQueue means that stale field values are sometimes seen for ConnectionListenerWrapper.hasPermit(). > Under heavy contention, a stale value in hasPermit() means permits.release() is not called and the semaphores available reduce over time. > The mcp effectively shrinks over time. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 09:29:40 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Tue, 18 Nov 2014 09:29:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1236) Race condition in SemaphoreConcurrentLinkedQueueManagedConnectionPool In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesper Pedersen resolved JBJCA-1236. ------------------------------------ Resolution: Done > Race condition in SemaphoreConcurrentLinkedQueueManagedConnectionPool > --------------------------------------------------------------------- > > Key: JBJCA-1236 > URL: https://issues.jboss.org/browse/JBJCA-1236 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.29.Final, 1.2.0.Final > Reporter: John O'Hara > Assignee: Jesper Pedersen > Fix For: 1.0.30.Final, 1.2.1.Final > > > A race condition in the ConnectionListenerWrapper and incorrect logic when returning the ConnectionListener object to the ConcurrentLinkedQueue means that stale field values are sometimes seen for ConnectionListenerWrapper.hasPermit(). > Under heavy contention, a stale value in hasPermit() means permits.release() is not called and the semaphores available reduce over time. > The mcp effectively shrinks over time. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 09:31:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 09:31:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-24) JARs Made Invalid By Patch Installation Should Be Renamed to Indicate Their Status In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020816#comment-13020816 ] RH Bugzilla Integration commented on WFCORE-24: ----------------------------------------------- Jimmy Wilson changed the Status of [bug 1085696|https://bugzilla.redhat.com/show_bug.cgi?id=1085696] from POST to CLOSED > JARs Made Invalid By Patch Installation Should Be Renamed to Indicate Their Status > ---------------------------------------------------------------------------------- > > Key: WFCORE-24 > URL: https://issues.jboss.org/browse/WFCORE-24 > Project: WildFly Core > Issue Type: Feature Request > Components: Patching > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 09:39:39 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Tue, 18 Nov 2014 09:39:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4094) SRD.SensitivityClassificationResource.isRuntime() to depend on the specified permissions In-Reply-To: References: Message-ID: Alexey Loubyansky created WFLY-4094: --------------------------------------- Summary: SRD.SensitivityClassificationResource.isRuntime() to depend on the specified permissions Key: WFLY-4094 URL: https://issues.jboss.org/browse/WFLY-4094 Project: WildFly Issue Type: Enhancement Components: Domain Management Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky As discussed with Brian Stansberry, it's worth making isRuntime() impl of org.jboss.as.domain.management.access.SensitivityResourceDefinition.SensitivityClassificationResource depend on the specified permissions. The implemented logic should be equivalent to the one in org.jboss.as.domain.management.parsing.ManagementXml.getSensitivityClassificationConstraints(...) where it is decided whether the constraints are present. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 10:21:39 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Tue, 18 Nov 2014 10:21:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-261) SRD.SensitivityClassificationResource.isRuntime() to depend on the specified permissions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Loubyansky moved WFLY-4094 to WFCORE-261: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-261 (was: WFLY-4094) Component/s: Domain Management (was: Domain Management) > SRD.SensitivityClassificationResource.isRuntime() to depend on the specified permissions > ---------------------------------------------------------------------------------------- > > Key: WFCORE-261 > URL: https://issues.jboss.org/browse/WFCORE-261 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > As discussed with Brian Stansberry, it's worth making isRuntime() impl of org.jboss.as.domain.management.access.SensitivityResourceDefinition.SensitivityClassificationResource depend on the specified permissions. The implemented logic should be equivalent to the one in org.jboss.as.domain.management.parsing.ManagementXml.getSensitivityClassificationConstraints(...) where it is decided whether the constraints are present. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 10:27:39 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Tue, 18 Nov 2014 10:27:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-262) use PlaceholderResource for host-environment and module-loading resources In-Reply-To: References: Message-ID: Alexey Loubyansky created WFCORE-262: ---------------------------------------- Summary: use PlaceholderResource for host-environment and module-loading resources Key: WFCORE-262 URL: https://issues.jboss.org/browse/WFCORE-262 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky host-environment and module-loading should be runtime resources. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 10:29:39 2014 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Tue, 18 Nov 2014 10:29:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4046) Container lifecycle event method invoked outside of extension observer method invocation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger resolved WFLY-4046. ----------------------------------- Resolution: Rejected Not a WildFly bug. Fixed in Camel. > Container lifecycle event method invoked outside of extension observer method invocation > ---------------------------------------------------------------------------------------- > > Key: WFLY-4046 > URL: https://issues.jboss.org/browse/WFLY-4046 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Thomas Diesler > Assignee: Jozef Hartinger > > Cannot deploy war that uses camel-cdi > This works in 8.1.0.Final > {code} > org.jboss.weld.exceptions.IllegalStateException: WELD-000143: Container lifecycle event method invoked outside of extension observer method invocation. > at org.jboss.weld.bootstrap.events.ContainerEvent.checkWithinObserverNotification(ContainerEvent.java:61) > at org.jboss.weld.bootstrap.events.ProcessAnnotatedTypeImpl.getAnnotatedType(ProcessAnnotatedTypeImpl.java:56) > at org.apache.camel.cdi.internal.CamelContextConfig.configure(CamelContextConfig.java:47) > at org.apache.camel.cdi.internal.CamelContextBean.configureCamelContext(CamelContextBean.java:131) > at org.apache.camel.cdi.internal.CamelExtension.startConsumeBeans(CamelExtension.java:231) > {code} > Camel Issue: https://issues.apache.org/jira/browse/CAMEL-7992 > Github Issue: https://github.com/wildflyext/wildfly-camel/issues/52 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 11:11:40 2014 From: issues at jboss.org (Dan Berindei (JIRA)) Date: Tue, 18 Nov 2014 11:11:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1901) GMS: view installation by consensus In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020847#comment-13020847 ] Dan Berindei commented on JGRP-1901: ------------------------------------ I think Radim is right. If a node already have a view installed, then it shouldn't just ACK a view from a new coordinator. But I wouldn't add another timeout on each member. Instead I would add some restrictions on the new view: 1. The new view's id is should be greater than the old one's, so the node wouldn't bounce from one coordinator to another when the network is patchy. 2. If the new view is not a merge view, the new coordinator should be a member of the old view. If the old coordinator is a member of the view, it should be the new coordinator as well. 3. A merge view should be accepted only if we replied to the merge request from the merge coordinator. We should track the accepted merge requests and only accept one merge request at a time (old merge requests should eventually time out). If a node actively nacks a view update, the coordinator should be able to retry installing a view without that particular node, and eventually start a new merge round. I'm not sure how workable this is, and you may not like the strong connection to the merge protocol. But I think JGroups needs to be a lot more conservative about changing the coordinator. > GMS: view installation by consensus > ----------------------------------- > > Key: JGRP-1901 > URL: https://issues.jboss.org/browse/JGRP-1901 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > Investigate whether view installation should optionally be done via 2PC. Example: > * View is A,B,C,D, splits into A,B and C,D > * Before AB is installed in A and B, view A,B,C is installed > ** (C hasn't been suspected yet. This can happen with {{FD}}) > Infinispan's rebalancing algorithm has problems with this, as it tries to assign state to C which however isn't reachable from the A,B side of the network partition. It would be better if A,B,C,D went directly to A,B and C,D > Investigate whether we should add a property to {{GMS}} which defines whether to use 2PC for view installation (default would be {{false}}). The algorithm would work as follows: > * Send a {{PREPARE_VIEW(view)}} message > * When all responses have been received -> send a {{COMMIT_VIEW}} message > * Else > ** Inject SUSPECT(C) event for all misisng acks OR > ** Set a timer to go off in N ms -> when it fires, send the {{COMMIT_VIEW}} msg > ** If another view is installed before the tmer goes off (e.g. A,B) -> kill the timer -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 11:20:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 18 Nov 2014 11:20:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-620) Interval rule consequence actions not processed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020850#comment-13020850 ] Mario Fusco commented on DROOLS-620: ------------------------------------ Fix improved by https://github.com/droolsjbpm/drools/commit/2b30dc12e > Interval rule consequence actions not processed > ----------------------------------------------- > > Key: DROOLS-620 > URL: https://issues.jboss.org/browse/DROOLS-620 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta1 > Environment: MacBook Pro, OS X 10.9.5 > Reporter: Roger Lefebvre > Assignee: Mario Fusco > Fix For: 6.2.0.CR2 > > > Actions defined in the consequence of a rule with an defined interval (e.g. cron) are not processed by the system. Inserted facts, modified fields and pushed agenda groups are not consumed resulting in other rules not being fired. If you execute fireAllRules from code, it will then process the consequence actions. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 11:29:40 2014 From: issues at jboss.org (Anderson Parra de Paula (JIRA)) Date: Tue, 18 Nov 2014 11:29:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4075) Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020855#comment-13020855 ] Anderson Parra de Paula commented on WFLY-4075: ----------------------------------------------- There is a bug on build step to copy file resteasy-spring.jar to modules/system/layers/base/org/jboss/resteasy/resteasy-spring/main/bundled/resteasy-spring-jar When you start an application that uses this jar an NullPointerException is thrown by class JaxrsSpringProcessor. I have created a pull request to fix it: https://github.com/wildfly/wildfly/pull/6969 > Setting "org.jboss.as.jaxrs.enableSpringIntegration" to "true" causes JaxrsSpringProcessor to throw NullPointerException > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4075 > URL: https://issues.jboss.org/browse/WFLY-4075 > Project: WildFly > Issue Type: Bug > Components: REST, VFS > Affects Versions: 9.0.0.Alpha1 > Reporter: Jay Kumar SenSharma > Assignee: Tomaz Cerar > Attachments: WFLY-4075_Reproducer_And_Log.zip > > > - When an application containing Spring + Rest Integration is deployed on Wildfly then it causes NullPointerException as following: > {code} > 13:43:19,830 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "RESTfulExample.war" (runtime-name: "RESTfulExample.war") > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring-form.tld > 13:43:20,313 ERROR [org.wildfly.extension.undertow] (MSC service thread 1-4) Could not find tld /WEB-INF/tld/spring.tld > 13:43:20,370 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."RESTfulExample.war".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "RESTfulExample.war" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:203) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.0.Alpha8.jar:1.0.0.Alpha8] > ... 5 more > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:133) > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.deploy(JaxrsSpringProcessor.java:199) > ... 6 more > Caused by: java.lang.NullPointerException > at org.jboss.as.jaxrs.deployment.JaxrsSpringProcessor.getResteasySpringVirtualFile(JaxrsSpringProcessor.java:103) > ... 7 more > 13:43:20,374 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "RESTfulExample.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"RESTfulExample.war\".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment \"RESTfulExample.war\" > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 11:54:39 2014 From: issues at jboss.org (Anderson Parra de Paula (JIRA)) Date: Tue, 18 Nov 2014 11:54:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4088) NPE when changing scheduled service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020867#comment-13020867 ] Anderson Parra de Paula commented on WFLY-4088: ----------------------------------------------- Hi Alarik. How are you? I cannot simulate this issue. Please, take a look in my snapshot log. Can you send more details about your project configuration? 16:46:17,580 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeplo ymentUnitProcessor] (MSC service thread 1-4) JNDI bindings for session bean name d TimerTest in deployment unit subdeployment "sample-ejb-ejb.jar" of deployment "sample-ejb-ear.ear" are as follows: java:global/sample-ejb-ear/sample-ejb-ejb/TimerTest!org.jboss.as.quickst arts.ear.ejb.TimerTest java:app/sample-ejb-ejb/TimerTest!org.jboss.as.quickstarts.ear.ejb.Timer Test java:module/TimerTest!org.jboss.as.quickstarts.ear.ejb.TimerTest java:global/sample-ejb-ear/sample-ejb-ejb/TimerTest java:app/sample-ejb-ejb/TimerTest java:module/TimerTest 16:46:17,627 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016005 : Starting Services for CDI deployment: sample-ejb-ear.ear 16:46:17,674 INFO [org.jboss.weld.Version] (MSC service thread 1-6) WELD-000900 : 2.1.2 (Final) 16:46:17,689 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016008 : Starting weld service for deployment sample-ejb-ear.ear 16:46:19,000 INFO [stdout] (EJB default - 9) Hello 16:46:19,015 INFO [stdout] (EJB default - 10) Hello 16:46:19,015 INFO [stdout] (EJB default - 2) Hello 16:46:19,015 INFO [stdout] (EJB default - 8) Hello 16:46:19,015 INFO [stdout] (EJB default - 3) Hello 16:46:19,015 INFO [stdout] (EJB default - 1) Hello 16:46:19,031 INFO [stdout] (EJB default - 5) Hello 16:46:19,031 INFO [stdout] (EJB default - 6) Hello 16:46:19,031 INFO [stdout] (EJB default - 7) Hello 16:46:19,031 INFO [stdout] (EJB default - 4) Hello 16:46:19,592 INFO [stdout] (EJB default - 1) Hello 16:46:19,608 INFO [stdout] (EJB default - 9) Hello 16:46:19,670 INFO [stdout] (EJB default - 4) Hello > NPE when changing scheduled service > ----------------------------------- > > Key: WFLY-4088 > URL: https://issues.jboss.org/browse/WFLY-4088 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Alarik Myrin > Assignee: David Lloyd > > If I modify or remove a (persistent) scheduled service, I get the following stack trace: > Caused by: java.lang.NullPointerException > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.doesTimeoutMethodMatch(TimerServiceImpl.java:959) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:710) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.start(TimerServiceImpl.java:202) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final] > ... 3 more > Another user is reporting the same thing on 8.1.0 Final, see: > http://stackoverflow.com/questions/25988818/deploying-java-schedule-with-wildfly-8-1-0-final > Is there any way using the CLI to delete persistent scheduled services? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 11:59:39 2014 From: issues at jboss.org (Alarik Myrin (JIRA)) Date: Tue, 18 Nov 2014 11:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4088) NPE when changing scheduled service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020868#comment-13020868 ] Alarik Myrin commented on WFLY-4088: ------------------------------------ I think what I did was to re-deploy a .war file in which a timed service had disappeared. So in the old version of the .war file, there was a timed service, and in the new version of the .war file, there was no timed service. And it caused the problem. Undeploying a .war file does not remove the persistent timed services (seemingly by design), so it was only through Googling the problem that I learned how I could deploy my new version of the .war file that no longer had the timed service. > NPE when changing scheduled service > ----------------------------------- > > Key: WFLY-4088 > URL: https://issues.jboss.org/browse/WFLY-4088 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Alarik Myrin > Assignee: David Lloyd > > If I modify or remove a (persistent) scheduled service, I get the following stack trace: > Caused by: java.lang.NullPointerException > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.doesTimeoutMethodMatch(TimerServiceImpl.java:959) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:710) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.start(TimerServiceImpl.java:202) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.Final.jar:1.2.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.Final.jar:1.2.0.Final] > ... 3 more > Another user is reporting the same thing on 8.1.0 Final, see: > http://stackoverflow.com/questions/25988818/deploying-java-schedule-with-wildfly-8-1-0-final > Is there any way using the CLI to delete persistent scheduled services? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 12:08:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 12:08:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-260) Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020877#comment-13020877 ] RH Bugzilla Integration commented on WFCORE-260: ------------------------------------------------ Darran Lofthouse changed the Status of [bug 1161589|https://bugzilla.redhat.com/show_bug.cgi?id=1161589] from ASSIGNED to POST > Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab > ------------------------------------------------------------------------------------------ > > Key: WFCORE-260 > URL: https://issues.jboss.org/browse/WFCORE-260 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 13:41:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 18 Nov 2014 13:41:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-648) Bottleneck during the creation of the object type configurations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-648: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Bottleneck during the creation of the object type configurations > ---------------------------------------------------------------- > > Key: DROOLS-648 > URL: https://issues.jboss.org/browse/DROOLS-648 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.CR1 > Reporter: Yehudit Glass > Assignee: Mario Fusco > Priority: Critical > > There is indeed a bottleneck during the creation of the object type configurations. > On insert facts to state full session it cause drools to go to ProjectClassLoader.loadClasss code which is synchronize and block threads which led to bad performance (when working multi threading). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 13:43:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Tue, 18 Nov 2014 13:43:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-648) Bottleneck during the creation of the object type configurations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-648. -------------------------------- Fix Version/s: 6.2.0.CR3 Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/37378c42a > Bottleneck during the creation of the object type configurations > ---------------------------------------------------------------- > > Key: DROOLS-648 > URL: https://issues.jboss.org/browse/DROOLS-648 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.CR1 > Reporter: Yehudit Glass > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.2.0.CR3 > > > There is indeed a bottleneck during the creation of the object type configurations. > On insert facts to state full session it cause drools to go to ProjectClassLoader.loadClasss code which is synchronize and block threads which led to bad performance (when working multi threading). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 15:11:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 15:11:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4082) Upgrade Generic JMS RA to 1.0.7.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020929#comment-13020929 ] RH Bugzilla Integration commented on WFLY-4082: ----------------------------------------------- Kabir Khan changed the Status of [bug 1164213|https://bugzilla.redhat.com/show_bug.cgi?id=1164213] from POST to MODIFIED > Upgrade Generic JMS RA to 1.0.7.Final > ------------------------------------- > > Key: WFLY-4082 > URL: https://issues.jboss.org/browse/WFLY-4082 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 15:11:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 18 Nov 2014 15:11:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-865) Setting transaction timeout on UserTransaction leaks to the thread and doesn't get cleared In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020931#comment-13020931 ] RH Bugzilla Integration commented on WFLY-865: ---------------------------------------------- Kabir Khan changed the Status of [bug 900984|https://bugzilla.redhat.com/show_bug.cgi?id=900984] from NEW to MODIFIED > Setting transaction timeout on UserTransaction leaks to the thread and doesn't get cleared > ------------------------------------------------------------------------------------------ > > Key: WFLY-865 > URL: https://issues.jboss.org/browse/WFLY-865 > Project: WildFly > Issue Type: Bug > Components: EE, Transactions > Reporter: jaikiran pai > Assignee: David Lloyd > > A user has reported (with an example) that setting a transaction timeout on the UserTransaction will leak the timeout onto the thread and subsequent transaction creation on that thread uses the leaked value instead of new values. > More details in the referenced forum thread. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 15:34:39 2014 From: issues at jboss.org (Frank Langelage (JIRA)) Date: Tue, 18 Nov 2014 15:34:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4095) Upgrade Infinispan to 7.0.1.Final In-Reply-To: References: Message-ID: Frank Langelage created WFLY-4095: ------------------------------------- Summary: Upgrade Infinispan to 7.0.1.Final Key: WFLY-4095 URL: https://issues.jboss.org/browse/WFLY-4095 Project: WildFly Issue Type: Component Upgrade Affects Versions: 9.0.0.Beta1 Reporter: Frank Langelage Assignee: Jason Greene Fix For: 9.0.0.Beta1 Update Infinispan from 7.0.0.Final to 7.0.1.Final including sub-component upgrade of Hibernate Search from 5.0.0.Beta1 to 5.0.0.Beta2. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 15:46:39 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Tue, 18 Nov 2014 15:46:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-236) getDeclaredMethod with multiple methods of same name In-Reply-To: References: Message-ID: Shigeru Chiba created JASSIST-236: ------------------------------------- Summary: getDeclaredMethod with multiple methods of same name Key: JASSIST-236 URL: https://issues.jboss.org/browse/JASSIST-236 Project: Javassist Issue Type: Feature Request Affects Versions: 3.18.2-GA Reporter: Shigeru Chiba Assignee: Shigeru Chiba Priority: Minor Fix For: 3.19.0-GA would it be possible to add a method in CtClass to retrieve all methods of a given name. Actually the behavior of getDeclaredMethod when there are multiple overloads is to return one of them. Original: https://github.com/jboss-javassist/javassist/issues/9 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 21:15:41 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Tue, 18 Nov 2014 21:15:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: shinzey shinzey created WFLY-4096: ------------------------------------- Summary: Datasource Defined in web.xml Does Not Work with JPA Entity Manager Key: WFLY-4096 URL: https://issues.jboss.org/browse/WFLY-4096 Project: WildFly Issue Type: Bug Components: JPA / Hibernate, Web (JBoss Web) Affects Versions: 8.1.0.Final Environment: Windows 7 Java 8u25 WildFly 8.1.0.Final Reporter: shinzey shinzey Assignee: Scott Marlow Priority: Critical The datasource defined in web.xml: {quote} java:/datasources/test org.apache.derby.jdbc.ClientDataSource test jdbc:derby://localhost:1527/test test test {quote} The persistence unit: {quote} java:/datasources/test {quote} The deployment error: {quote} 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]} 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] {quote} If I remove the persistence unit, the datasource can be successfully bound: {quote} 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 18 21:18:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Tue, 18 Nov 2014 21:18:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shinzey shinzey updated WFLY-4096: ---------------------------------- Description: The datasource defined in web.xml: {quote} java:/datasources/test org.apache.derby.jdbc.ClientDataSource test jdbc:derby://localhost:1527/test test test {quote} The persistence unit: {quote} java:/datasources/test {quote} The deployment error: {quote} 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] {quote} If I remove the persistence unit, the datasource can be successfully bound: {quote} 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] {quote} was: The datasource defined in web.xml: {quote} java:/datasources/test org.apache.derby.jdbc.ClientDataSource test jdbc:derby://localhost:1527/test test test {quote} The persistence unit: {quote} java:/datasources/test {quote} The deployment error: {quote} 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]} 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] {quote} If I remove the persistence unit, the datasource can be successfully bound: {quote} 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] {quote} > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 00:59:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Wed, 19 Nov 2014 00:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4097) JAX-RS Returnes Wrong Repsonse Code When A Method Is Not Allowed In-Reply-To: References: Message-ID: shinzey shinzey created WFLY-4097: ------------------------------------- Summary: JAX-RS Returnes Wrong Repsonse Code When A Method Is Not Allowed Key: WFLY-4097 URL: https://issues.jboss.org/browse/WFLY-4097 Project: WildFly Issue Type: Bug Components: EJB, REST, Security Affects Versions: 8.1.0.Final Environment: Windows 7 Java 8u25 WildFly 8.1.0.Final Reporter: shinzey shinzey Assignee: David Lloyd Priority: Critical My RESTful service is protected with @RolesAllowed: {quote} @Stateless @RolesAllowed("admin") @Path("admin") {quote} When a non-admin user is trying to request this service, it fails with a HTTP 500 response, instead of 401. From the log we can see that @RolesAllowed is working as expected: {quote} org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public zhyi.wildweb.AdminService zhyi.wildweb.AdminService.getUsers() of bean: AdminService is not allowed {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 01:01:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Wed, 19 Nov 2014 01:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4097) JAX-RS Returnes Wrong Repsonse Code When A Method Is Not Allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shinzey shinzey updated WFLY-4097: ---------------------------------- Description: My RESTful service is protected with @RolesAllowed: {quote} @Stateless @RolesAllowed("admin") @Path("admin") {quote} When a non-admin user is trying to request this service, it fails with 500 Internal Server Error, instead of 401 Unauthorized. From the log we can see that @RolesAllowed is working as expected: {quote} org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public zhyi.wildweb.AdminService zhyi.wildweb.AdminService.getUsers() of bean: AdminService is not allowed {quote} was: My RESTful service is protected with @RolesAllowed: {quote} @Stateless @RolesAllowed("admin") @Path("admin") {quote} When a non-admin user is trying to request this service, it fails with a HTTP 500 response, instead of 401. From the log we can see that @RolesAllowed is working as expected: {quote} org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public zhyi.wildweb.AdminService zhyi.wildweb.AdminService.getUsers() of bean: AdminService is not allowed {quote} > JAX-RS Returnes Wrong Repsonse Code When A Method Is Not Allowed > ---------------------------------------------------------------- > > Key: WFLY-4097 > URL: https://issues.jboss.org/browse/WFLY-4097 > Project: WildFly > Issue Type: Bug > Components: EJB, REST, Security > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: David Lloyd > Priority: Critical > > My RESTful service is protected with @RolesAllowed: > {quote} > @Stateless > @RolesAllowed("admin") > @Path("admin") > {quote} > When a non-admin user is trying to request this service, it fails with 500 Internal Server Error, instead of 401 Unauthorized. From the log we can see that @RolesAllowed is working as expected: > {quote} > org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public zhyi.wildweb.AdminService zhyi.wildweb.AdminService.getUsers() of bean: AdminService is not allowed > {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 01:01:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Wed, 19 Nov 2014 01:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4097) JAX-RS Returns Wrong Repsonse Code When A Method Is Not Allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shinzey shinzey updated WFLY-4097: ---------------------------------- Summary: JAX-RS Returns Wrong Repsonse Code When A Method Is Not Allowed (was: JAX-RS Returnes Wrong Repsonse Code When A Method Is Not Allowed) > JAX-RS Returns Wrong Repsonse Code When A Method Is Not Allowed > --------------------------------------------------------------- > > Key: WFLY-4097 > URL: https://issues.jboss.org/browse/WFLY-4097 > Project: WildFly > Issue Type: Bug > Components: EJB, REST, Security > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: David Lloyd > Priority: Critical > > My RESTful service is protected with @RolesAllowed: > {quote} > @Stateless > @RolesAllowed("admin") > @Path("admin") > {quote} > When a non-admin user is trying to request this service, it fails with 500 Internal Server Error, instead of 401 Unauthorized. From the log we can see that @RolesAllowed is working as expected: > {quote} > org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public zhyi.wildweb.AdminService zhyi.wildweb.AdminService.getUsers() of bean: AdminService is not allowed > {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 01:24:39 2014 From: issues at jboss.org (James Livingston (JIRA)) Date: Wed, 19 Nov 2014 01:24:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken In-Reply-To: References: Message-ID: James Livingston created WFCORE-263: --------------------------------------- Summary: Cancelling management op on slave HC tree is broken Key: WFCORE-263 URL: https://issues.jboss.org/browse/WFCORE-263 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha9 Reporter: James Livingston Assignee: Brian Stansberry If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progression operations will be reported for both the DC and the slave HC via: /host=master/core-service=management/service=management-operations:find-non-progressing-operation /host=slave/core-service=management/service=management-operations:find-non-progressing-operation Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 01:30:39 2014 From: issues at jboss.org (James Livingston (JIRA)) Date: Wed, 19 Nov 2014 01:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Livingston updated WFCORE-263: ------------------------------------ Description: If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via: /host=master/core-service=management/service=management-operations:find-non-progressing-operation /host=slave/core-service=management/service=management-operations:find-non-progressing-operation Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. was: If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progression operations will be reported for both the DC and the slave HC via: /host=master/core-service=management/service=management-operations:find-non-progressing-operation /host=slave/core-service=management/service=management-operations:find-non-progressing-operation Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. > Cancelling management op on slave HC tree is broken > --------------------------------------------------- > > Key: WFCORE-263 > URL: https://issues.jboss.org/browse/WFCORE-263 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha9 > Reporter: James Livingston > Assignee: Brian Stansberry > > If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via: > /host=master/core-service=management/service=management-operations:find-non-progressing-operation > /host=slave/core-service=management/service=management-operations:find-non-progressing-operation > Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. > If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. > Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. > Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 02:16:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 02:16:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020993#comment-13020993 ] RH Bugzilla Integration commented on WFCORE-213: ------------------------------------------------ Emmanuel Hugonnet (ehsavoie) changed the Status of [bug 1018026|https://bugzilla.redhat.com/show_bug.cgi?id=1018026] from NEW to POST > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14, 1.0.0.Beta1 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 02:53:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 02:53:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2732) Injected EJB not available to MDB @PreDestroy methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021009#comment-13021009 ] RH Bugzilla Integration commented on WFLY-2732: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1103786|https://bugzilla.redhat.com/show_bug.cgi?id=1103786] from MODIFIED to ON_QA > Injected EJB not available to MDB @PreDestroy methods > ----------------------------------------------------- > > Key: WFLY-2732 > URL: https://issues.jboss.org/browse/WFLY-2732 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 8.0.0.Final > > Attachments: MDBLifeCycleJAR.zip > > > MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed. > This was fixed in an RFE for Session Beans but does not seem to work for MDB. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 02:58:39 2014 From: issues at jboss.org (Jim Ma (JIRA)) Date: Wed, 19 Nov 2014 02:58:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-866) Add jboss module option to ServerLoginModule In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Ma resolved SECURITY-866. ----------------------------- Assignee: Jim Ma Resolution: Done > Add jboss module option to ServerLoginModule > -------------------------------------------- > > Key: SECURITY-866 > URL: https://issues.jboss.org/browse/SECURITY-866 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Jim Ma > > If the callback class isn't in the picketbox module or the deployment module, there is module option can be provided to define the module path for the callback class or validator class. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 04:14:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 04:14:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-795) jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021028#comment-13021028 ] RH Bugzilla Integration commented on WFLY-795: ---------------------------------------------- Kabir Khan changed the Status of [bug 1028412|https://bugzilla.redhat.com/show_bug.cgi?id=1028412] from POST to MODIFIED > jboss-ejb-iiop_1_0.xsd has both use="required" and default attributes on some elements > -------------------------------------------------------------------------------------- > > Key: WFLY-795 > URL: https://issues.jboss.org/browse/WFLY-795 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: James Livingston > Assignee: David Lloyd > Fix For: 8.0.0.CR1 > > > In jboss-ejb-iiop_1_0.xsd, the "integrity", "confidentiality", "establish-trust-in-client", and "establish-trust-in-target" attributes on the "iorTransportConfigType" complexType, and the "auth-method", "realm" and "required" attributes on the "iorASContextType" complexType have both use="required" and a default attribute. > This does not make sense because default values are only applicable to optional attributes. I'm not sure which is correct, but either the attributes should be optional or the default values removed. This problem causes the XSD to not validate. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 05:25:40 2014 From: issues at jboss.org (Dan Berindei (JIRA)) Date: Wed, 19 Nov 2014 05:25:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1902) Simplify failure detection and merge timeout configuration In-Reply-To: References: Message-ID: Dan Berindei created JGRP-1902: ---------------------------------- Summary: Simplify failure detection and merge timeout configuration Key: JGRP-1902 URL: https://issues.jboss.org/browse/JGRP-1902 Project: JGroups Issue Type: Enhancement Affects Versions: 3.6 Reporter: Dan Berindei Assignee: Bela Ban Fix For: 4.0 FD/FD_ALL/FD_ALL2/FD_SOCK javadoc doesn't give any guidance as to how long it would take to detect a leaving member. MERGE2/MERGE3 javadoc also doesn't say how much it would take to detect that the network has healed. For an example of how misleading the current settings can be, I have seen MERGE3 take more than 20s to merge two partitions with min_interval=1000 and max_interval=5000. FD also detects a leaver after {{timeout * max_tries}} in the best case, and twice that if 2 consecutive nodes (in the members list) leave at the same time. The maximum time it takes to detect a leaver is of particular interest to Infinispan users, because Infinispan is supposed to protect against nodes leaving. But if the users don't configure a high enough RPC timeout in Infinispan, we don't get to detect the node leaving. Ideally, the user should be able to specify a maximum detection time, and the protocol should adjust the existing settings to meet that (most of the time). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 06:03:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 19 Nov 2014 06:03:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1902) Simplify failure detection and merge timeout configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-1902: --------------------------- Fix Version/s: 3.6.1 > Simplify failure detection and merge timeout configuration > ---------------------------------------------------------- > > Key: JGRP-1902 > URL: https://issues.jboss.org/browse/JGRP-1902 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 3.6.1, 4.0 > > > FD/FD_ALL/FD_ALL2/FD_SOCK javadoc doesn't give any guidance as to how long it would take to detect a leaving member. MERGE2/MERGE3 javadoc also doesn't say how much it would take to detect that the network has healed. > For an example of how misleading the current settings can be, I have seen MERGE3 take more than 20s to merge two partitions with min_interval=1000 and max_interval=5000. FD also detects a leaver after {{timeout * max_tries}} in the best case, and twice that if 2 consecutive nodes (in the members list) leave at the same time. > The maximum time it takes to detect a leaver is of particular interest to Infinispan users, because Infinispan is supposed to protect against nodes leaving. But if the users don't configure a high enough RPC timeout in Infinispan, we don't get to detect the node leaving. > Ideally, the user should be able to specify a maximum detection time, and the protocol should adjust the existing settings to meet that (most of the time). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 07:04:39 2014 From: issues at jboss.org (Madhu Garimilla (JIRA)) Date: Wed, 19 Nov 2014 07:04:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AS7-4265) cli command to add/remove AS modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021108#comment-13021108 ] Madhu Garimilla commented on AS7-4265: -------------------------------------- David Jensen, Did you find a solution to this. I also have the same requirement, i need to create a module through CLI which would give the same module.xml that you have posted ie, Please post the solution if you find anything. > cli command to add/remove AS modules > ------------------------------------ > > Key: AS7-4265 > URL: https://issues.jboss.org/browse/AS7-4265 > Project: Application Server 7 > Issue Type: Task > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 7.1.2.Final (EAP) > > > I think it'd be useful to have a command to add modules to the AS which given the jars, dependencies, etc would generate the structure in the modules dir, copy the jars and generate the xml. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 08:07:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 08:07:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-851) Base64Utils class cuts leading zeroes from encoded bytes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021133#comment-13021133 ] RH Bugzilla Integration commented on SECURITY-851: -------------------------------------------------- Peter Skopek changed the Status of [bug 1125004|https://bugzilla.redhat.com/show_bug.cgi?id=1125004] from POST to ON_QA > Base64Utils class cuts leading zeroes from encoded bytes > -------------------------------------------------------- > > Key: SECURITY-851 > URL: https://issues.jboss.org/browse/SECURITY-851 > Project: PicketBox > Issue Type: Bug > Affects Versions: PicketBox_4_0_21.Beta2 > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Blocker > Fix For: PicketBox_4_0_21.Final > > > Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array. > So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes. > For instance: > {code} > encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho" > decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 } > {code} > As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException. > IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 08:08:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 08:08:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-788) PicketBoxSecurityVault is not writing data to store after removing from map in memory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021134#comment-13021134 ] RH Bugzilla Integration commented on SECURITY-788: -------------------------------------------------- Peter Skopek changed the Status of [bug 1153614|https://bugzilla.redhat.com/show_bug.cgi?id=1153614] from POST to ON_QA > PicketBoxSecurityVault is not writing data to store after removing from map in memory > ------------------------------------------------------------------------------------- > > Key: SECURITY-788 > URL: https://issues.jboss.org/browse/SECURITY-788 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: PicketBox_4_0_21.Beta1 > > > PicketBoxSecurityVault is not writing data to store after removing from map in memory. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 08:09:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 08:09:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3789) Vault cannot be initialized with external password provided by CLASS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021136#comment-13021136 ] RH Bugzilla Integration commented on WFLY-3789: ----------------------------------------------- Peter Skopek changed the Status of [bug 1146006|https://bugzilla.redhat.com/show_bug.cgi?id=1146006] from POST to ON_QA > Vault cannot be initialized with external password provided by CLASS > --------------------------------------------------------------------- > > Key: WFLY-3789 > URL: https://issues.jboss.org/browse/WFLY-3789 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Filip Bogyai > Assignee: Peter Skopek > > When vault is configured to use external password obtained from CLASS, e.g. :{code:xml} {code} > WildFly is unable to start, because of ClassNotFoundException: > {code} > 11:00:40,696 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("core-service" => "vault")]): java.lang.RuntimeException: WFLYSRV0076: Error initializing vault -- org.jboss.as.server.services.security.VaultReaderException: WFLYSEC0017: Vault Reader Exception: > at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:88) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:657) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:498) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:299) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:294) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1072) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:375) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:297) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.server.ServerService.boot(ServerService.java:373) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.server.ServerService.boot(ServerService.java:348) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:259) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > Caused by: org.jboss.as.server.services.security.VaultReaderException: WFLYSEC0017: Vault Reader Exception: > at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:99) [wildfly-security-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:86) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > ... 12 more > Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.ClassNotFoundException: org.jboss.security.plugins.TmpFilePassword from [Module "org.jboss.as.controller:main" from local module loader @4be525ab > at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:97) [wildfly-security-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > ... 13 more > Caused by: java.lang.ClassNotFoundException: org.jboss.security.plugins.TmpFilePassword from [Module "org.jboss.as.controller:main" from local module loader @4be525ab > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final] > at org.jboss.security.Util.invokePasswordClass(Util.java:174) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.jboss.security.Util.loadPassword(Util.java:126) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.picketbox.plugins.vault.PicketBoxSecurityVault.loadKeystorePassword(PicketBoxSecurityVault.java:343) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:204) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > ... 14 more > {code} > External passwords for vault were introduces by RFE: SECURITY-831 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 08:12:39 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Wed, 19 Nov 2014 08:12:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-236) getDeclaredMethod with multiple methods of same name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shigeru Chiba resolved JASSIST-236. ----------------------------------- Resolution: Done > getDeclaredMethod with multiple methods of same name > ---------------------------------------------------- > > Key: JASSIST-236 > URL: https://issues.jboss.org/browse/JASSIST-236 > Project: Javassist > Issue Type: Feature Request > Affects Versions: 3.18.2-GA > Reporter: Shigeru Chiba > Assignee: Shigeru Chiba > Priority: Minor > Fix For: 3.19.0-GA > > > would it be possible to add a method in CtClass to retrieve all methods of a given name. Actually the behavior of getDeclaredMethod when there are multiple overloads is to return one of them. > Original: > https://github.com/jboss-javassist/javassist/issues/9 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 08:12:39 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Wed, 19 Nov 2014 08:12:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-236) getDeclaredMethod with multiple methods of same name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shigeru Chiba closed JASSIST-236. --------------------------------- > getDeclaredMethod with multiple methods of same name > ---------------------------------------------------- > > Key: JASSIST-236 > URL: https://issues.jboss.org/browse/JASSIST-236 > Project: Javassist > Issue Type: Feature Request > Affects Versions: 3.18.2-GA > Reporter: Shigeru Chiba > Assignee: Shigeru Chiba > Priority: Minor > Fix For: 3.19.0-GA > > > would it be possible to add a method in CtClass to retrieve all methods of a given name. Actually the behavior of getDeclaredMethod when there are multiple overloads is to return one of them. > Original: > https://github.com/jboss-javassist/javassist/issues/9 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 08:17:40 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 19 Nov 2014 08:17:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-253) Remoting subsystem sasl-protocol and server-name should support expressions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse reopened WFCORE-253: ------------------------------------- An additional change is needed to the validators. > Remoting subsystem sasl-protocol and server-name should support expressions > --------------------------------------------------------------------------- > > Key: WFCORE-253 > URL: https://issues.jboss.org/browse/WFCORE-253 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 08:19:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 19 Nov 2014 08:19:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-264) server-name and sasl-protocol on the management interfaces don't fully support expressions. In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-264: --------------------------------------- Summary: server-name and sasl-protocol on the management interfaces don't fully support expressions. Key: WFCORE-264 URL: https://issues.jboss.org/browse/WFCORE-264 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha14 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 08:33:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 08:33:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-788) PicketBoxSecurityVault is not writing data to store after removing from map in memory In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021154#comment-13021154 ] RH Bugzilla Integration commented on SECURITY-788: -------------------------------------------------- jtymel at redhat.com changed the Status of [bug 1153614|https://bugzilla.redhat.com/show_bug.cgi?id=1153614] from ON_QA to VERIFIED > PicketBoxSecurityVault is not writing data to store after removing from map in memory > ------------------------------------------------------------------------------------- > > Key: SECURITY-788 > URL: https://issues.jboss.org/browse/SECURITY-788 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Affects Versions: PicketBox_4_0_20.Final > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: PicketBox_4_0_21.Beta1 > > > PicketBoxSecurityVault is not writing data to store after removing from map in memory. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 08:41:39 2014 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Wed, 19 Nov 2014 08:41:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021160#comment-13021160 ] Scott Marlow commented on WFLY-4096: ------------------------------------ [https://community.jboss.org/en/wildfly?view=discussions] is the best place to ask questions like this. The question to ask would of been something like, "how can I get a Datasource defined in web.xml to work with JPA Entity Manager?" Have you tried adding a hibernate.temp.use_jdbc_metadata_defaults? Probably not, I just found out about this property a few weeks ago myself. There are other ways that we can talk about but try that first. If that doesn't help, we can probably discuss the other ways in the above user forums, so let me know either way. {quote} java:/datasources/test {quote} > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 09:47:41 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 19 Nov 2014 09:47:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021204#comment-13021204 ] Brian Stansberry commented on WFCORE-263: ----------------------------------------- "rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled." What happens if you invoke the "cancel" operation on active-operation=xxx resource with the problematic operation? > Cancelling management op on slave HC tree is broken > --------------------------------------------------- > > Key: WFCORE-263 > URL: https://issues.jboss.org/browse/WFCORE-263 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha9 > Reporter: James Livingston > Assignee: Brian Stansberry > > If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via: > /host=master/core-service=management/service=management-operations:find-non-progressing-operation > /host=slave/core-service=management/service=management-operations:find-non-progressing-operation > Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. > If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. > Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. > Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 10:27:40 2014 From: issues at jboss.org (David Jensen (JIRA)) Date: Wed, 19 Nov 2014 10:27:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (AS7-4265) cli command to add/remove AS modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/AS7-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021222#comment-13021222 ] David Jensen commented on AS7-4265: ----------------------------------- Hi Madhu. I have not found a solution. This is unfortunate because using an automated script would be very nice. > cli command to add/remove AS modules > ------------------------------------ > > Key: AS7-4265 > URL: https://issues.jboss.org/browse/AS7-4265 > Project: Application Server 7 > Issue Type: Task > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 7.1.2.Final (EAP) > > > I think it'd be useful to have a command to add modules to the AS which given the jars, dependencies, etc would generate the structure in the modules dir, copy the jars and generate the xml. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 10:55:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 10:55:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4093) Changing IOR settings should require restart of jacorb subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021239#comment-13021239 ] RH Bugzilla Integration commented on WFLY-4093: ----------------------------------------------- Kabir Khan changed the Status of [bug 1080333|https://bugzilla.redhat.com/show_bug.cgi?id=1080333] from POST to MODIFIED > Changing IOR settings should require restart of jacorb subsystem > ---------------------------------------------------------------- > > Key: WFLY-4093 > URL: https://issues.jboss.org/browse/WFLY-4093 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 9.0.0.Alpha1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: 9.0.0.Beta1 > > > When using management operations to add IOR settings, the settings don't get reflected in the IORSecConfigMetaDataService until a server reload. The management operations should mark that the jacorb subsystem needs to be restarted. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 11:27:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 19 Nov 2014 11:27:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-354) Support EJB 2.0 dtd descriptors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd reassigned JBMETA-354: ---------------------------------- Assignee: David Lloyd > Support EJB 2.0 dtd descriptors > ------------------------------- > > Key: JBMETA-354 > URL: https://issues.jboss.org/browse/JBMETA-354 > Project: JBoss Metadata > Issue Type: Bug > Components: ejb > Affects Versions: 7.0.0.Final > Reporter: Carlo de Wolf > Assignee: David Lloyd > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 11:28:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Wed, 19 Nov 2014 11:28:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-354) Support EJB 2.0 dtd descriptors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated JBMETA-354: ------------------------------- Assignee: (was: David Lloyd) > Support EJB 2.0 dtd descriptors > ------------------------------- > > Key: JBMETA-354 > URL: https://issues.jboss.org/browse/JBMETA-354 > Project: JBoss Metadata > Issue Type: Bug > Components: ejb > Affects Versions: 7.0.0.Final > Reporter: Carlo de Wolf > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 11:41:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 11:41:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3789) Vault cannot be initialized with external password provided by CLASS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021264#comment-13021264 ] RH Bugzilla Integration commented on WFLY-3789: ----------------------------------------------- FIlip Bogyai changed the Status of [bug 1146006|https://bugzilla.redhat.com/show_bug.cgi?id=1146006] from ON_QA to VERIFIED > Vault cannot be initialized with external password provided by CLASS > --------------------------------------------------------------------- > > Key: WFLY-3789 > URL: https://issues.jboss.org/browse/WFLY-3789 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Filip Bogyai > Assignee: Peter Skopek > > When vault is configured to use external password obtained from CLASS, e.g. :{code:xml} {code} > WildFly is unable to start, because of ClassNotFoundException: > {code} > 11:00:40,696 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("core-service" => "vault")]): java.lang.RuntimeException: WFLYSRV0076: Error initializing vault -- org.jboss.as.server.services.security.VaultReaderException: WFLYSEC0017: Vault Reader Exception: > at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:88) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:657) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:498) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:299) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:294) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1072) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:375) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:297) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.server.ServerService.boot(ServerService.java:373) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.server.ServerService.boot(ServerService.java:348) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:259) [wildfly-controller-1.0.0.Alpha4.jar:1.0.0.Alpha4] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > Caused by: org.jboss.as.server.services.security.VaultReaderException: WFLYSEC0017: Vault Reader Exception: > at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:99) [wildfly-security-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > at org.jboss.as.server.services.security.VaultAddHandler.performRuntime(VaultAddHandler.java:86) [wildfly-server-1.0.0.Alpha4.jar:1.0.0.Alpha4] > ... 12 more > Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.ClassNotFoundException: org.jboss.security.plugins.TmpFilePassword from [Module "org.jboss.as.controller:main" from local module loader @4be525ab > at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:210) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.jboss.as.security.vault.RuntimeVaultReader.createVault(RuntimeVaultReader.java:97) [wildfly-security-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT] > ... 13 more > Caused by: java.lang.ClassNotFoundException: org.jboss.security.plugins.TmpFilePassword from [Module "org.jboss.as.controller:main" from local module loader @4be525ab > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final] > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final] > at org.jboss.security.Util.invokePasswordClass(Util.java:174) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.jboss.security.Util.loadPassword(Util.java:126) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.picketbox.plugins.vault.PicketBoxSecurityVault.loadKeystorePassword(PicketBoxSecurityVault.java:343) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > at org.picketbox.plugins.vault.PicketBoxSecurityVault.init(PicketBoxSecurityVault.java:204) [picketbox-4.0.21.Beta3.jar:4.0.21.Beta3] > ... 14 more > {code} > External passwords for vault were introduces by RFE: SECURITY-831 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 13:08:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 19 Nov 2014 13:08:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-265) add-user not escaping the backslash '\' character in usernames. In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-265: --------------------------------------- Summary: add-user not escaping the backslash '\' character in usernames. Key: WFCORE-265 URL: https://issues.jboss.org/browse/WFCORE-265 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha14 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 13:34:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 13:34:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3969) HeaderTokenParser doesn't parse correctly values which includes a quote In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021301#comment-13021301 ] RH Bugzilla Integration commented on WFLY-3969: ----------------------------------------------- Darran Lofthouse changed the Status of [bug 1150024|https://bugzilla.redhat.com/show_bug.cgi?id=1150024] from ASSIGNED to POST > HeaderTokenParser doesn't parse correctly values which includes a quote > ----------------------------------------------------------------------- > > Key: WFLY-3969 > URL: https://issues.jboss.org/browse/WFLY-3969 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > Priority: Critical > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > The header parser doesn't work correctly if a parsed value contains quote character ("). The problem is, the parser is in phase of searching a LAST_QUOTE and it doesn't check if the found quote character is escaped or not. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 13:37:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 13:37:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3969) HeaderTokenParser doesn't parse correctly values which includes a quote In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021304#comment-13021304 ] RH Bugzilla Integration commented on WFLY-3969: ----------------------------------------------- Darran Lofthouse changed the Status of [bug 1150024|https://bugzilla.redhat.com/show_bug.cgi?id=1150024] from POST to ASSIGNED > HeaderTokenParser doesn't parse correctly values which includes a quote > ----------------------------------------------------------------------- > > Key: WFLY-3969 > URL: https://issues.jboss.org/browse/WFLY-3969 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > Priority: Critical > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > The header parser doesn't work correctly if a parsed value contains quote character ("). The problem is, the parser is in phase of searching a LAST_QUOTE and it doesn't check if the found quote character is escaped or not. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 13:38:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 13:38:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3969) HeaderTokenParser doesn't parse correctly values which includes a quote In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021305#comment-13021305 ] RH Bugzilla Integration commented on WFLY-3969: ----------------------------------------------- Darran Lofthouse changed the Status of [bug 1150024|https://bugzilla.redhat.com/show_bug.cgi?id=1150024] from ASSIGNED to POST > HeaderTokenParser doesn't parse correctly values which includes a quote > ----------------------------------------------------------------------- > > Key: WFLY-3969 > URL: https://issues.jboss.org/browse/WFLY-3969 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > Priority: Critical > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > The header parser doesn't work correctly if a parsed value contains quote character ("). The problem is, the parser is in phase of searching a LAST_QUOTE and it doesn't check if the found quote character is escaped or not. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 13:54:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 13:54:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-202) Deadlock when shutdown Wildfly server during CLI client connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021307#comment-13021307 ] RH Bugzilla Integration commented on WFCORE-202: ------------------------------------------------ Kabir Khan changed the Status of [bug 1151960|https://bugzilla.redhat.com/show_bug.cgi?id=1151960] from POST to MODIFIED > Deadlock when shutdown Wildfly server during CLI client connection > ------------------------------------------------------------------ > > Key: WFCORE-202 > URL: https://issues.jboss.org/browse/WFCORE-202 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha10 > Reporter: Chao Wang > Assignee: Alexey Loubyansky > Fix For: 1.0.0.Alpha13 > > > Creating upstream issue as the same deadlock can be found in WFLY. > Descirption as comment 5 in [BZ1142538|https://bugzilla.redhat.com/show_bug.cgi?id=1142538] > {noformat} > The following deadlock still exists. > Steps to Reproduce: > 1. Prepare a running EAP instance with secured management port - optionally in VM > 2. Execute export JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" > 3. In the same terminal, execute "bin/jboss-cli.sh --connect --controller=$EAP_IP --user=admin --password=password ':read-resource'" > 4. From yet another terminal, execute "jdb -attach localhost:8787" > 5. In JDB: > 5.a. Create breakpoint: "stop in org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 5.b. Resume all threads: "resume" > 5.c. [Execute five times] Wait until breakpoint is hit and execute "resume". Either set timeout or be fast so that timeout does not occur first > 6. Execute "kill -9 $EAP_PID" - optionally in VM > 7. In JDB: > 8.a. Remove breakpoint: "clear org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 8.b. Resume all threads: "resume" > 9. Now dump the stack trace of jboss-cli.sh: "kill -3 $JBOSS_CLI_PID" > Found one Java-level deadlock: > ============================= > "Remoting "cli-client" read-1": > waiting to lock monitor 0x00007ff9c829b558 (object 0x0000000783433408, a java.lang.String), > which is held by "main" > "main": > waiting to lock monitor 0x00007ff9c8333c48 (object 0x00000007851ae6e0, a java.util.ArrayDeque), > which is held by "Remoting "cli-client" read-1" > Java stack information for the threads listed above: > =================================================== > "Remoting "cli-client" read-1": > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:286) > - waiting to lock <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:269) > at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54) > at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:532) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) > at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:392) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:109) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:81) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:183) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.nio.NioHandle.run(NioHandle.java:90) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:198) > "main": > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:361) > - waiting to lock <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.connectionOpened(FutureManagementChannel.java:217) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:78) > - locked <0x0000000784978a00> (a org.jboss.as.protocol.ProtocolConnectionManager) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160) > - locked <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:123) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:98) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:980) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:841) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:817) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:250) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > 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:483) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > {noformat} > It can be easily reproduce with Eclipse as: > {noformat} > 1 start Wildfly > 2 uncomment "JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" in jboss-cli.sh and connect to server > 3 add two break points at > CLIModelControllerClient$ChannelCloseHandler [line: 285] - handleClose(Channel, IOException) > RemoteConnectionChannel [line: 360] - receiveMessage(Receiver) > 4 connect to 8787 from eclipse debug > 5 shutdown Wildfly > A deadlock between "main" and "cli-client" is in Eclipse debug stack. > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 13:55:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 13:55:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-245) Add tests for suffix option on size-rotating-file-handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021309#comment-13021309 ] RH Bugzilla Integration commented on WFCORE-245: ------------------------------------------------ Kabir Khan changed the Status of [bug 1160541|https://bugzilla.redhat.com/show_bug.cgi?id=1160541] from POST to MODIFIED > Add tests for suffix option on size-rotating-file-handler > --------------------------------------------------------- > > Key: WFCORE-245 > URL: https://issues.jboss.org/browse/WFCORE-245 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: Petr Kremensky > Assignee: James Perkins > > Add tests for WFCORE-113 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 14:04:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Wed, 19 Nov 2014 14:04:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-266) Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-266: --------------------------------------- Summary: Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params Key: WFCORE-266 URL: https://issues.jboss.org/browse/WFCORE-266 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Fix For: 1.0.0.CR1 Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD. So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well. CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 14:47:39 2014 From: issues at jboss.org (Stan Silvert (JIRA)) Date: Wed, 19 Nov 2014 14:47:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-267) CLI prints output twice if using cli client jar In-Reply-To: References: Message-ID: Stan Silvert created WFCORE-267: ----------------------------------- Summary: CLI prints output twice if using cli client jar Key: WFCORE-267 URL: https://issues.jboss.org/browse/WFCORE-267 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 1.0.0.Alpha13 Reporter: Stan Silvert Assignee: Stan Silvert Fix For: 1.0.0.Alpha14 If you are using the [CLI client jar|https://developer.jboss.org/wiki/UsingTheCLIRemoteClientJar], all output is printed twice. This is because JBoss logging is not set up and by default CommandContextImpl is printing log messages to standard out. The output will look something like this: {code} [standalone at localhost:9999 /] :read-children-types Nov 19, 2014 8:57:19 AM org.jboss.as.cli.impl.CommandContextImpl printLine INFO: { "outcome" => "success", "result" => [ "core-service", "deployment", "deployment-overlay", "extension", "interface", "path", "socket-binding-group", "subsystem", "system-property" ] } { "outcome" => "success", "result" => [ "core-service", "deployment", "deployment-overlay", "extension", "interface", "path", "socket-binding-group", "subsystem", "system-property" ] } {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 14:56:39 2014 From: issues at jboss.org (Stan Silvert (JIRA)) Date: Wed, 19 Nov 2014 14:56:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-268) CLI GUI fails if connecting to AS7 or EAP6 In-Reply-To: References: Message-ID: Stan Silvert created WFCORE-268: ----------------------------------- Summary: CLI GUI fails if connecting to AS7 or EAP6 Key: WFCORE-268 URL: https://issues.jboss.org/browse/WFCORE-268 Project: WildFly Core Issue Type: Bug Components: CLI Affects Versions: 1.0.0.Alpha13 Reporter: Stan Silvert Assignee: Stan Silvert Fix For: 1.0.0.Alpha14 If you try to use a WildFly version CLI GUI to connect to AS7 or EAP6, you will get a failure. The reason is because CLI GUI tries to do a list-log-files operation, which does not exist in those older AS versions. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 15:11:39 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 19 Nov 2014 15:11:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4098) Upgrade Infinispan to 7.0.2.Final In-Reply-To: References: Message-ID: Paul Ferraro created WFLY-4098: ---------------------------------- Summary: Upgrade Infinispan to 7.0.2.Final Key: WFLY-4098 URL: https://issues.jboss.org/browse/WFLY-4098 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 9.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 9.0.0.Beta1 Supercedes WFLY-4095 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 15:14:39 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 19 Nov 2014 15:14:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4095) Upgrade Infinispan to 7.0.1.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro closed WFLY-4095. ------------------------------ > Upgrade Infinispan to 7.0.1.Final > --------------------------------- > > Key: WFLY-4095 > URL: https://issues.jboss.org/browse/WFLY-4095 > Project: WildFly > Issue Type: Component Upgrade > Affects Versions: 9.0.0.Beta1 > Reporter: Frank Langelage > Assignee: Paul Ferraro > Fix For: 9.0.0.Beta1 > > > Update Infinispan from 7.0.0.Final to 7.0.1.Final including sub-component upgrade of Hibernate Search from 5.0.0.Beta1 to 5.0.0.Beta2. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 16:36:39 2014 From: issues at jboss.org (Davide Sottara (JIRA)) Date: Wed, 19 Nov 2014 16:36:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-652) Add support to event sequencing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Sottara moved JBRULES-3514 to DROOLS-652: ------------------------------------------------ Project: Drools (was: JBRULES) Key: DROOLS-652 (was: JBRULES-3514) Workflow: GIT Pull Request workflow (was: classic default workflow) Component/s: (was: drools-core) (was: drools-compiler) (was: drools-api) Fix Version/s: (was: 6.0.0.Alpha1) > Add support to event sequencing > ------------------------------- > > Key: DROOLS-652 > URL: https://issues.jboss.org/browse/DROOLS-652 > Project: Drools > Issue Type: Feature Request > Reporter: Edson Tirelli > Assignee: Edson Tirelli > > The purpose of this ticket is to centralize the discussions regarding the implementation of event sequencing as detailed in the wiki page at: > https://community.jboss.org/wiki/EventSequencing > The highlevel discussions can be added to this ticket while individual sub-tickets will be created for the implementation of each sub-feature. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 16:49:39 2014 From: issues at jboss.org (Mark Proctor (JIRA)) Date: Wed, 19 Nov 2014 16:49:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Duplicate method call inside patterns In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021346#comment-13021346 ] Mark Proctor commented on DROOLS-651: ------------------------------------- caching would not be cheap, it would require an array of Objects for each variable in each tuple. So it would probably add another 25% to over all memory usage. This would be over kill when typically most people are just doing person.age, so the additional cache is just wasted space with no performance gains. We could in the future look at allowing optional cached bindings, but right now it's lower priority and would add in a lot of complexity both on the engine and the language. > Duplicate method call inside patterns > ------------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mario Fusco > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 17:36:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 17:36:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1631) Duplicated message ids in web, undertow, jsf and osgi subsystems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021354#comment-13021354 ] RH Bugzilla Integration commented on WFLY-1631: ----------------------------------------------- Kabir Khan changed the Status of [bug 980823|https://bugzilla.redhat.com/show_bug.cgi?id=980823] from POST to MODIFIED > Duplicated message ids in web, undertow, jsf and osgi subsystems > ----------------------------------------------------------------- > > Key: WFLY-1631 > URL: https://issues.jboss.org/browse/WFLY-1631 > Project: WildFly > Issue Type: Bug > Components: JSF, OSGi, Web (Undertow) > Affects Versions: 8.0.0.Alpha2 > Reporter: Ivo Studensky > Assignee: Tomaz Cerar > Priority: Critical > Fix For: 8.0.0.CR1 > > > There is a lot of duplicated or different messages in JBossWeb and Undertow subsystems which has the same ids. > different messages: > {noformat} > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12604, value = "JSF version slot '%s' is missing from module %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12604, value = "WildFlyConversationAwareViewHandler was improperly initialized. Expected ViewHandler parent.") > {noformat} > duplicated messages with the same content: > {noformat} > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12600, value = "Could not load JSF managed bean class: %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12600, value = "Could not load JSF managed bean class: %s") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12601, value = "JSF managed bean class %s has no default constructor") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12601, value = "JSF managed bean class %s has no default constructor") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12602, value = "Failed to parse %s, managed beans defined in this file will not be available") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12602, value = "Failed to parse %s, managed beans defined in this file will not be available") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12603, value = "Unknown JSF version '%s'. Default version '%s' will be used instead.") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12603, value = "Unknown JSF version %s %s will be used instead") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12650, value = "Failed to load annotated class: %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12650, value = "Failed to load annotated class: %s") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12651, value = "Annotation %s in class %s is only allowed on classes") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12651, value = "Annotation %s in class %s is only allowed on classes") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12652, value = "Instance creation failed") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12652, value = "Instance creation failed") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12653, value = "Instance destruction failed") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12653, value = "Instance destruction failed") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12654, value = "Thread local injection container not set") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12654, value = "Thread local injection container not set") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12655, value = "@ManagedBean is only allowed at class level %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12655, value = "@ManagedBean is only allowed at class level %s") > web/src/main/java/org/jboss/as/web/WebMessages.java: @Message(id = 18039, value = "Failed to create context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18039, value = "Failed to create context") > web/src/main/java/org/jboss/as/web/WebMessages.java: @Message(id = 18040, value = "Failed to start context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18040, value = "Failed to start context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18200, value = "Failed to start welcome context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18200, value = "Failed to start welcome context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18201, value = "Failed to destroy welcome context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18201, value = "Failed to destroy welcome context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18202, value = "Error calling onStartup for servlet container initializer: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18202, value = "Error calling onStartup for servlet container initializer: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18203, value = "Error instantiating container component: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18203, value = "Error instantiating container component: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18204, value = "Clustering not supported, falling back to non-clustered session manager") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18204, value = "Clustering not supported, falling back to non-clustered session manager") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18205, value = "Cannot setup overlays for [%s] due to custom resources") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18205, value = "Cannot setup overlays for [%s] due to custom resources") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18206, value = "Webapp [%s] is unavailable due to startup errors") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18206, value = "Webapp [%s] is unavailable due to startup errors") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18208, value = "Failed to start context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18208, value = "Failed to start context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18209, value = "Failed to destroy context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18209, value = "Failed to destroy context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18210, value = "Register web context: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18210, value = "Register web context: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18214, value = "Error during login/password authenticate") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18214, value = "Error during login/password authenticate") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18215, value = "Error during certificate authenticate") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18215, value = "Error during certificate authenticate") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18216, value = "Error during digest authenticate") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18216, value = "Error during digest authenticate") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18217, value = "Error obtaining authorization helper") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18217, value = "Error obtaining authorization helper") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18218, value = "Exception in obtaining server authentication manager") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18218, value = "Exception in obtaining server authentication manager") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18219, value = "JASPI validation for unprotected request context %s failed") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18219, value = "JASPI validation for unprotected request context %s failed") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18220, value = "Caught Exception: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18220, value = "Caught Exception: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18221, value = "Error forwarding to login page: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18221, value = "Error forwarding to login page: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18222, value = "Error forwarding to error page: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18222, value = "Error forwarding to error page: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18224, value = "Unregister web context: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18224, value = "Unregister web context: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18226, value = "Skipped SCI for jar: %s.") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18226, value = "Skipped SCI for jar: %s.") > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 17:36:39 2014 From: issues at jboss.org (Frank Langelage (JIRA)) Date: Wed, 19 Nov 2014 17:36:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4099) NameNotFoundException: clustering/group/ejb In-Reply-To: References: Message-ID: Frank Langelage created WFLY-4099: ------------------------------------- Summary: NameNotFoundException: clustering/group/ejb Key: WFLY-4099 URL: https://issues.jboss.org/browse/WFLY-4099 Project: WildFly Issue Type: Bug Components: Web Console Affects Versions: 9.0.0.Beta1 Reporter: Frank Langelage Assignee: Heiko Braun Clicking on "JNDI View" in the admin web-console adds this error message to server.log: 19.11. 23:30:40,998 ERROR [org.jboss.as.naming#addEntries] WFLYNAM0013: Failed to obtain jndi view value for entry ejb.: javax.naming.NameNotFoundException: clustering/group/ejb [Root exception is java.lang.IllegalStateException] at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:132) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:137) at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:137) at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:47) at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:72) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:728) at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:563) at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:336) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:312) at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1163) at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:356) at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:215) at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:207) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:415) at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68) at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63) at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56) at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:83) at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:767) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalStateException at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) at org.jboss.as.naming.service.BinderService.getValue(BinderService.java:138) at org.jboss.as.naming.service.BinderService.getValue(BinderService.java:46) at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:131) ... 31 more Server is running in standalone mode. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 17:37:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 17:37:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-259) Improve realm readiness handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021355#comment-13021355 ] RH Bugzilla Integration commented on WFCORE-259: ------------------------------------------------ Kabir Khan changed the Status of [bug 1161668|https://bugzilla.redhat.com/show_bug.cgi?id=1161668] from POST to MODIFIED > Improve realm readiness handling > -------------------------------- > > Key: WFCORE-259 > URL: https://issues.jboss.org/browse/WFCORE-259 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > Currently we display an error message informing users that they need to add a new user if any of the authentication mechanisms within a realm report that they are not ready to handle requests. > The reason for this was so that if properties backed authentication we available along with local authentication then the local authentication would not prevent the prompt from being displayed. > However there could be additional mechanisms suitable for use with HTTP so we need a small modification to stop taking into account the local authentication mechanism but allow requests in if any of the other HTTP compatible mechanisms are ready to handle requests. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 17:38:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 19 Nov 2014 17:38:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-260) Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021357#comment-13021357 ] RH Bugzilla Integration commented on WFCORE-260: ------------------------------------------------ Kabir Khan changed the Status of [bug 1161589|https://bugzilla.redhat.com/show_bug.cgi?id=1161589] from POST to MODIFIED > Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab > ------------------------------------------------------------------------------------------ > > Key: WFCORE-260 > URL: https://issues.jboss.org/browse/WFCORE-260 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 18:02:39 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 19 Nov 2014 18:02:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4100) Intermittent failure in org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase In-Reply-To: References: Message-ID: Paul Ferraro created WFLY-4100: ---------------------------------- Summary: Intermittent failure in org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase Key: WFLY-4100 URL: https://issues.jboss.org/browse/WFLY-4100 Project: WildFly Issue Type: Bug Components: Clustering, EJB Affects Versions: 9.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 18:03:40 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 19 Nov 2014 18:03:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4100) Intermittent failure in org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro updated WFLY-4100: ------------------------------- Description: {noformat} javax.ejb.EJBException: java.lang.IllegalStateException: WFLYCLEJBINF0008: Stateful session bean {[-89, -53, -3, -58, 52, -115, 78, 79, -106, -9, -119, 3, 0, 35, -10, -106]} refers to an invalid bean group 6c5836ab-086a-464c-8ae9-29e1a79a8254 at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.createBean(InfinispanBeanFactory.java:75) at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:266) at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:115) at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:58) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:280) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:345) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:622) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:243) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184) at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.as.test.integration.ejb.remote.client.api.interceptor.SimpleEJBClientInterceptor.handleInvocation(SimpleEJBClientInterceptor.java:48) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) at com.sun.proxy.$Proxy328.getManagedBeanMessage(Unknown Source) at org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase.testPassivationMaxSize(PassivationTestCase.java:103) {noformat} > Intermittent failure in org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase > -------------------------------------------------------------------------------------------------- > > Key: WFLY-4100 > URL: https://issues.jboss.org/browse/WFLY-4100 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > {noformat} > javax.ejb.EJBException: java.lang.IllegalStateException: WFLYCLEJBINF0008: Stateful session bean {[-89, -53, -3, -58, 52, -115, 78, 79, -106, -9, -119, 3, 0, 35, -10, -106]} refers to an invalid bean group 6c5836ab-086a-464c-8ae9-29e1a79a8254 > at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.createBean(InfinispanBeanFactory.java:75) > at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:266) > at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:115) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:58) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:280) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:345) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:622) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:243) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184) > at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) > at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) > at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) > at org.jboss.as.test.integration.ejb.remote.client.api.interceptor.SimpleEJBClientInterceptor.handleInvocation(SimpleEJBClientInterceptor.java:48) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) > at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) > at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) > at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) > at com.sun.proxy.$Proxy328.getManagedBeanMessage(Unknown Source) > at org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase.testPassivationMaxSize(PassivationTestCase.java:103) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 18:04:39 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Wed, 19 Nov 2014 18:04:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4100) Intermittent failure in org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro updated WFLY-4100: ------------------------------- Description: Seems to be a transactional issue with Infinispan eviction. {noformat} javax.ejb.EJBException: java.lang.IllegalStateException: WFLYCLEJBINF0008: Stateful session bean {[-89, -53, -3, -58, 52, -115, 78, 79, -106, -9, -119, 3, 0, 35, -10, -106]} refers to an invalid bean group 6c5836ab-086a-464c-8ae9-29e1a79a8254 at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.createBean(InfinispanBeanFactory.java:75) at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:266) at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:115) at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:58) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:280) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:345) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:622) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:243) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184) at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.as.test.integration.ejb.remote.client.api.interceptor.SimpleEJBClientInterceptor.handleInvocation(SimpleEJBClientInterceptor.java:48) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) at com.sun.proxy.$Proxy328.getManagedBeanMessage(Unknown Source) at org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase.testPassivationMaxSize(PassivationTestCase.java:103) {noformat} was: {noformat} javax.ejb.EJBException: java.lang.IllegalStateException: WFLYCLEJBINF0008: Stateful session bean {[-89, -53, -3, -58, 52, -115, 78, 79, -106, -9, -119, 3, 0, 35, -10, -106]} refers to an invalid bean group 6c5836ab-086a-464c-8ae9-29e1a79a8254 at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.createBean(InfinispanBeanFactory.java:75) at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:266) at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:115) at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:58) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:280) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:345) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:622) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:243) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184) at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.as.test.integration.ejb.remote.client.api.interceptor.SimpleEJBClientInterceptor.handleInvocation(SimpleEJBClientInterceptor.java:48) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) at com.sun.proxy.$Proxy328.getManagedBeanMessage(Unknown Source) at org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase.testPassivationMaxSize(PassivationTestCase.java:103) {noformat} > Intermittent failure in org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase > -------------------------------------------------------------------------------------------------- > > Key: WFLY-4100 > URL: https://issues.jboss.org/browse/WFLY-4100 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 9.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Seems to be a transactional issue with Infinispan eviction. > {noformat} > javax.ejb.EJBException: java.lang.IllegalStateException: WFLYCLEJBINF0008: Stateful session bean {[-89, -53, -3, -58, 52, -115, 78, 79, -106, -9, -119, 3, 0, 35, -10, -106]} refers to an invalid bean group 6c5836ab-086a-464c-8ae9-29e1a79a8254 > at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.createBean(InfinispanBeanFactory.java:75) > at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:266) > at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:115) > at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:58) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:280) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:345) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:44) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:622) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:326) > at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:243) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:184) > at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) > at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) > at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) > at org.jboss.as.test.integration.ejb.remote.client.api.interceptor.SimpleEJBClientInterceptor.handleInvocation(SimpleEJBClientInterceptor.java:48) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) > at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) > at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:186) > at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) > at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) > at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) > at com.sun.proxy.$Proxy328.getManagedBeanMessage(Unknown Source) > at org.jboss.as.test.integration.ejb.stateful.passivation.PassivationTestCase.testPassivationMaxSize(PassivationTestCase.java:103) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 18:07:39 2014 From: issues at jboss.org (Richard Achmatowicz (JIRA)) Date: Wed, 19 Nov 2014 18:07:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021366#comment-13021366 ] Richard Achmatowicz commented on WFLY-1067: ------------------------------------------- We (Paul, Rado, myself, Tristan) met with Darran and to discuss this issue a while back. He gave us a run down of Elytron and we gave him a run down of the needs of ENCRYPT for security configuration information, in particular, access to keystores which support SecretKeys. The overall conclusion was that we might be able to get the necessary access via existing mechanisms, or existing mechanisms with some small changes, IIRC. What follow are further details on how that might be achieved. > Integrate JGroups with core AS security infrastructure > ------------------------------------------------------ > > Key: WFLY-1067 > URL: https://issues.jboss.org/browse/WFLY-1067 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security > Reporter: Brian Stansberry > Assignee: Richard Achmatowicz > > Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components. > Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 18:15:40 2014 From: issues at jboss.org (Davide Sottara (JIRA)) Date: Wed, 19 Nov 2014 18:15:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Bindings do not cache actual values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Sottara updated DROOLS-651: ---------------------------------- Summary: Bindings do not cache actual values (was: Duplicate method call inside patterns) > Bindings do not cache actual values > ----------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mario Fusco > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 18:18:39 2014 From: issues at jboss.org (Davide Sottara (JIRA)) Date: Wed, 19 Nov 2014 18:18:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Bindings do not cache actual values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021368#comment-13021368 ] Davide Sottara commented on DROOLS-651: --------------------------------------- Marc, if you are worried about the performance in some specific cases, you can always do the following: {code} $x : X() $y : Y() from $x.extremelyExpensiveMethodCall() {code} Now, $y will contain the "cached" result and will not require the reevaluation of the expression - at least until $x is updated. We will update the documentation as you suggest, but we will probably reject this feature request If you still see a use case where this would not be enough, please let us know Davide > Bindings do not cache actual values > ----------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mario Fusco > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 18:23:39 2014 From: issues at jboss.org (Richard Achmatowicz (JIRA)) Date: Wed, 19 Nov 2014 18:23:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021369#comment-13021369 ] Richard Achmatowicz commented on WFLY-1067: ------------------------------------------- Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm There are two issues: - configuration of SASL/ENCRYPT via existing security realm XML elements - accessing the configured security realm data from the associated services for injection into ENCRYPT existing security realm configuration --------------------------------------------- Relevant to this discussion, the security realm contains the following XML configuration elements: where:: - the element is designed for setting up key material for an SSLContext for incoming remote connections - the element is designed for setting up key material for SSL two way authentication configuration: JGroups SASL layer -------------------------------------------- The existing SASL integration (in JDG) makes use of the configuration in . The JGroups SASL layer supports these mechanisms: SASL mechanism -> SecurityRealm mechanism -> CallbackHandler PLAIN -> PLAIN -> PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler DIGEST_MD5 -> DIGEST -> PropertiesCallbackHandler, UserDomainCallbackHandler GSSAPI -> PLAIN EXTERNAL -> CLIENT_CERT -> ClientCertCallbackHandler where: - mechanism determines the way in which user data is handled/encoded between client and server - callback handler determines how the user data is actually obtained So, for example: - if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the or elements with user information - if we want to use the PLAIN mechanism, we should populate the , , or elements with user information In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs. configuration: JGroups ENCRYPT layer -------------------------------------------------- The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use: - symmetric encryption: a keystore for storing a single secret key - asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment) As we need a keystore for ENCRYPT usage, should we: - reuse the element for this purpose? - create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. reuse option ------------------------ If we did reuse the element, we would need to cater to the situation where: - need to provide SSL two way authentication for incoming connections (using both the and the elements) and - need to use the keystore to additionally store secret keys, public keys and private keys for ENCRYPT This could be achieved by: - sharing a single element between the incoming connections requiring SSL and JGroups peers joining a group - always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the element for both cases Some small problems: 1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the attribute provider="JCEKS". 2. The other problem here is that access to the service representing the keystore is not intended for public consumption. The element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore. Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do. use option ------------------------------- If we create a new element of to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT. Reuse of the element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity. > Integrate JGroups with core AS security infrastructure > ------------------------------------------------------ > > Key: WFLY-1067 > URL: https://issues.jboss.org/browse/WFLY-1067 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security > Reporter: Brian Stansberry > Assignee: Richard Achmatowicz > > Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components. > Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 18:25:39 2014 From: issues at jboss.org (Richard Achmatowicz (JIRA)) Date: Wed, 19 Nov 2014 18:25:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021369#comment-13021369 ] Richard Achmatowicz edited comment on WFLY-1067 at 11/19/14 6:25 PM: --------------------------------------------------------------------- Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm There are two issues: - configuration of SASL/ENCRYPT via existing security realm XML elements - accessing the configured security realm data from the associated services for injection into ENCRYPT existing security realm configuration --------------------------------------------- Relevant to this discussion, the security realm contains the following XML configuration elements: {code:xml} {code} where:: - the element is designed for setting up key material for an SSLContext for incoming remote connections - the element is designed for setting up key material for SSL two way authentication configuration: JGroups SASL layer -------------------------------------------- The existing SASL integration (in JDG) makes use of the configuration in . The JGroups SASL layer supports these mechanisms: SASL mechanism -> SecurityRealm mechanism -> CallbackHandler PLAIN -> PLAIN -> PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler DIGEST_MD5 -> DIGEST -> PropertiesCallbackHandler, UserDomainCallbackHandler GSSAPI -> PLAIN EXTERNAL -> CLIENT_CERT -> ClientCertCallbackHandler where: - mechanism determines the way in which user data is handled/encoded between client and server - callback handler determines how the user data is actually obtained So, for example: - if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the or elements with user information - if we want to use the PLAIN mechanism, we should populate the , , or elements with user information In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs. configuration: JGroups ENCRYPT layer -------------------------------------------------- The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use: - symmetric encryption: a keystore for storing a single secret key - asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment) As we need a keystore for ENCRYPT usage, should we: - reuse the element for this purpose? - create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. reuse option ------------------------ If we did reuse the element, we would need to cater to the situation where: - need to provide SSL two way authentication for incoming connections (using both the and the elements) and - need to use the keystore to additionally store secret keys, public keys and private keys for ENCRYPT This could be achieved by: - sharing a single element between the incoming connections requiring SSL and JGroups peers joining a group - always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the element for both cases Some small problems: 1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the attribute provider="JCEKS". 2. The other problem here is that access to the service representing the keystore is not intended for public consumption. The element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore. Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do. use option ------------------------------- If we create a new element of to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT. Reuse of the element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity. was (Author: rachmato): Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm There are two issues: - configuration of SASL/ENCRYPT via existing security realm XML elements - accessing the configured security realm data from the associated services for injection into ENCRYPT existing security realm configuration --------------------------------------------- Relevant to this discussion, the security realm contains the following XML configuration elements: where:: - the element is designed for setting up key material for an SSLContext for incoming remote connections - the element is designed for setting up key material for SSL two way authentication configuration: JGroups SASL layer -------------------------------------------- The existing SASL integration (in JDG) makes use of the configuration in . The JGroups SASL layer supports these mechanisms: SASL mechanism -> SecurityRealm mechanism -> CallbackHandler PLAIN -> PLAIN -> PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler DIGEST_MD5 -> DIGEST -> PropertiesCallbackHandler, UserDomainCallbackHandler GSSAPI -> PLAIN EXTERNAL -> CLIENT_CERT -> ClientCertCallbackHandler where: - mechanism determines the way in which user data is handled/encoded between client and server - callback handler determines how the user data is actually obtained So, for example: - if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the or elements with user information - if we want to use the PLAIN mechanism, we should populate the , , or elements with user information In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs. configuration: JGroups ENCRYPT layer -------------------------------------------------- The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use: - symmetric encryption: a keystore for storing a single secret key - asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment) As we need a keystore for ENCRYPT usage, should we: - reuse the element for this purpose? - create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. reuse option ------------------------ If we did reuse the element, we would need to cater to the situation where: - need to provide SSL two way authentication for incoming connections (using both the and the elements) and - need to use the keystore to additionally store secret keys, public keys and private keys for ENCRYPT This could be achieved by: - sharing a single element between the incoming connections requiring SSL and JGroups peers joining a group - always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the element for both cases Some small problems: 1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the attribute provider="JCEKS". 2. The other problem here is that access to the service representing the keystore is not intended for public consumption. The element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore. Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do. use option ------------------------------- If we create a new element of to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT. Reuse of the element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity. > Integrate JGroups with core AS security infrastructure > ------------------------------------------------------ > > Key: WFLY-1067 > URL: https://issues.jboss.org/browse/WFLY-1067 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security > Reporter: Brian Stansberry > Assignee: Richard Achmatowicz > > Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components. > Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 18:28:39 2014 From: issues at jboss.org (Richard Achmatowicz (JIRA)) Date: Wed, 19 Nov 2014 18:28:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021369#comment-13021369 ] Richard Achmatowicz edited comment on WFLY-1067 at 11/19/14 6:28 PM: --------------------------------------------------------------------- Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm There are two issues: - configuration of SASL/ENCRYPT via existing security realm XML elements - accessing the configured security realm data from the associated services for injection into ENCRYPT existing security realm configuration --------------------------------------------- Relevant to this discussion, the security realm contains the following XML configuration elements: {code:xml} {code} where:: - the element is designed for setting up key material for an SSLContext for incoming remote connections - the element is designed for setting up key material for SSL two way authentication configuration: JGroups SASL layer -------------------------------------------- The existing SASL integration (in JDG) makes use of the configuration in . The JGroups SASL layer supports these mechanisms: ||SASL mechanism || SecurityRealm mechanism || CallbackHandler || | PLAIN | PLAIN | PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler| | DIGEST_MD5 | DIGEST | PropertiesCallbackHandler, UserDomainCallbackHandler | | GSSAPI | PLAIN | (see above)| |EXTERNAL | CLIENT_CERT | ClientCertCallbackHandler| where: - mechanism determines the way in which user data is handled/encoded between client and server - callback handler determines how the user data is actually obtained So, for example: - if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the or elements with user information - if we want to use the PLAIN mechanism, we should populate the , , or elements with user information In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs. configuration: JGroups ENCRYPT layer -------------------------------------------------- The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use: - symmetric encryption: a keystore for storing a single secret key - asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment) As we need a keystore for ENCRYPT usage, should we: - reuse the element for this purpose? - create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. reuse option ------------------------ If we did reuse the element, we would need to cater to the situation where: - need to provide SSL two way authentication for incoming connections (using both the and the elements) and - need to use the keystore to additionally store secret keys, public keys and private keys for ENCRYPT This could be achieved by: - sharing a single element between the incoming connections requiring SSL and JGroups peers joining a group - always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the element for both cases Some small problems: 1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the attribute provider="JCEKS". 2. The other problem here is that access to the service representing the keystore is not intended for public consumption. The element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore. Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do. use option ------------------------------- If we create a new element of to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT. Reuse of the element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity. was (Author: rachmato): Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm There are two issues: - configuration of SASL/ENCRYPT via existing security realm XML elements - accessing the configured security realm data from the associated services for injection into ENCRYPT existing security realm configuration --------------------------------------------- Relevant to this discussion, the security realm contains the following XML configuration elements: {code:xml} {code} where:: - the element is designed for setting up key material for an SSLContext for incoming remote connections - the element is designed for setting up key material for SSL two way authentication configuration: JGroups SASL layer -------------------------------------------- The existing SASL integration (in JDG) makes use of the configuration in . The JGroups SASL layer supports these mechanisms: SASL mechanism -> SecurityRealm mechanism -> CallbackHandler PLAIN -> PLAIN -> PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler DIGEST_MD5 -> DIGEST -> PropertiesCallbackHandler, UserDomainCallbackHandler GSSAPI -> PLAIN EXTERNAL -> CLIENT_CERT -> ClientCertCallbackHandler where: - mechanism determines the way in which user data is handled/encoded between client and server - callback handler determines how the user data is actually obtained So, for example: - if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the or elements with user information - if we want to use the PLAIN mechanism, we should populate the , , or elements with user information In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs. configuration: JGroups ENCRYPT layer -------------------------------------------------- The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use: - symmetric encryption: a keystore for storing a single secret key - asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment) As we need a keystore for ENCRYPT usage, should we: - reuse the element for this purpose? - create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. reuse option ------------------------ If we did reuse the element, we would need to cater to the situation where: - need to provide SSL two way authentication for incoming connections (using both the and the elements) and - need to use the keystore to additionally store secret keys, public keys and private keys for ENCRYPT This could be achieved by: - sharing a single element between the incoming connections requiring SSL and JGroups peers joining a group - always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the element for both cases Some small problems: 1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the attribute provider="JCEKS". 2. The other problem here is that access to the service representing the keystore is not intended for public consumption. The element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore. Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do. use option ------------------------------- If we create a new element of to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT. Reuse of the element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity. > Integrate JGroups with core AS security infrastructure > ------------------------------------------------------ > > Key: WFLY-1067 > URL: https://issues.jboss.org/browse/WFLY-1067 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security > Reporter: Brian Stansberry > Assignee: Richard Achmatowicz > > Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components. > Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 18:28:39 2014 From: issues at jboss.org (Richard Achmatowicz (JIRA)) Date: Wed, 19 Nov 2014 18:28:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021369#comment-13021369 ] Richard Achmatowicz edited comment on WFLY-1067 at 11/19/14 6:28 PM: --------------------------------------------------------------------- Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm There are two issues: - configuration of SASL/ENCRYPT via existing security realm XML elements - accessing the configured security realm data from the associated services for injection into ENCRYPT existing security realm configuration --------------------------------------------- Relevant to this discussion, the security realm contains the following XML configuration elements: {code:xml} {code} where:: - the element is designed for setting up key material for an SSLContext for incoming remote connections - the element is designed for setting up key material for SSL two way authentication configuration: JGroups SASL layer -------------------------------------------- The existing SASL integration (in JDG) makes use of the configuration in . The JGroups SASL layer supports these mechanisms: ||SASL mechanism || SecurityRealm mechanism || CallbackHandler || | PLAIN | PLAIN | PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler| | DIGEST_MD5 | DIGEST | PropertiesCallbackHandler, UserDomainCallbackHandler | | GSSAPI | PLAIN | (see above)| |EXTERNAL | CLIENT_CERT | ClientCertCallbackHandler| where: - mechanism determines the way in which user data is handled/encoded between client and server - callback handler determines how the user data is actually obtained So, for example: - if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the or elements with user information - if we want to use the PLAIN mechanism, we should populate the , , or elements with user information In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs. configuration: JGroups ENCRYPT layer -------------------------------------------------- The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use: - symmetric encryption: a keystore for storing a single secret key - asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment) As we need a keystore for ENCRYPT usage, should we: - reuse the element for this purpose? - create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. reuse option ------------------------ If we did reuse the element, we would need to cater to the situation where: - need to provide SSL two way authentication for incoming connections (using both the and the elements) and - need to use the keystore to additionally store secret keys, public keys and private keys for ENCRYPT This could be achieved by: - sharing a single element between the incoming connections requiring SSL and JGroups peers joining a group - always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the element for both cases Some small problems: 1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the attribute provider="JCEKS". 2. The other problem here is that access to the service representing the keystore is not intended for public consumption. The element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore. Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do. use option ------------------------------- If we create a new element of to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT. Reuse of the element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity. was (Author: rachmato): Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm There are two issues: - configuration of SASL/ENCRYPT via existing security realm XML elements - accessing the configured security realm data from the associated services for injection into ENCRYPT existing security realm configuration --------------------------------------------- Relevant to this discussion, the security realm contains the following XML configuration elements: {code:xml} {code} where:: - the element is designed for setting up key material for an SSLContext for incoming remote connections - the element is designed for setting up key material for SSL two way authentication configuration: JGroups SASL layer -------------------------------------------- The existing SASL integration (in JDG) makes use of the configuration in . The JGroups SASL layer supports these mechanisms: ||SASL mechanism || SecurityRealm mechanism || CallbackHandler || | PLAIN | PLAIN | PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler| | DIGEST_MD5 | DIGEST | PropertiesCallbackHandler, UserDomainCallbackHandler | | GSSAPI | PLAIN | (see above)| |EXTERNAL | CLIENT_CERT | ClientCertCallbackHandler| where: - mechanism determines the way in which user data is handled/encoded between client and server - callback handler determines how the user data is actually obtained So, for example: - if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the or elements with user information - if we want to use the PLAIN mechanism, we should populate the , , or elements with user information In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs. configuration: JGroups ENCRYPT layer -------------------------------------------------- The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use: - symmetric encryption: a keystore for storing a single secret key - asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment) As we need a keystore for ENCRYPT usage, should we: - reuse the element for this purpose? - create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. reuse option ------------------------ If we did reuse the element, we would need to cater to the situation where: - need to provide SSL two way authentication for incoming connections (using both the and the elements) and - need to use the keystore to additionally store secret keys, public keys and private keys for ENCRYPT This could be achieved by: - sharing a single element between the incoming connections requiring SSL and JGroups peers joining a group - always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the element for both cases Some small problems: 1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the attribute provider="JCEKS". 2. The other problem here is that access to the service representing the keystore is not intended for public consumption. The element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore. Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do. use option ------------------------------- If we create a new element of to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT. Reuse of the element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity. > Integrate JGroups with core AS security infrastructure > ------------------------------------------------------ > > Key: WFLY-1067 > URL: https://issues.jboss.org/browse/WFLY-1067 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security > Reporter: Brian Stansberry > Assignee: Richard Achmatowicz > > Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components. > Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 18:29:39 2014 From: issues at jboss.org (Richard Achmatowicz (JIRA)) Date: Wed, 19 Nov 2014 18:29:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021369#comment-13021369 ] Richard Achmatowicz edited comment on WFLY-1067 at 11/19/14 6:29 PM: --------------------------------------------------------------------- Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm There are two issues: - configuration of SASL/ENCRYPT via existing security realm XML elements - accessing the configured security realm data from the associated services for injection into ENCRYPT existing security realm configuration --------------------------------------------- Relevant to this discussion, the security realm contains the following XML configuration elements: {code:xml} {code} where:: - the element is designed for setting up key material for an SSLContext for incoming remote connections - the element is designed for setting up key material for SSL two way authentication configuration: JGroups SASL layer -------------------------------------------- The existing SASL integration (in JDG) makes use of the configuration in . The JGroups SASL layer supports these mechanisms: ||SASL mechanism employed || SecurityRealm mechanism used || CallbackHandler available || | PLAIN | PLAIN | PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler| | DIGEST_MD5 | DIGEST | PropertiesCallbackHandler, UserDomainCallbackHandler | | GSSAPI | PLAIN | (see above)| |EXTERNAL | CLIENT_CERT | ClientCertCallbackHandler| where: - mechanism determines the way in which user data is handled/encoded between client and server - callback handler determines how the user data is actually obtained So, for example: - if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the or elements with user information - if we want to use the PLAIN mechanism, we should populate the , , or elements with user information In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs. configuration: JGroups ENCRYPT layer -------------------------------------------------- The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use: - symmetric encryption: a keystore for storing a single secret key - asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment) As we need a keystore for ENCRYPT usage, should we: - reuse the element for this purpose? - create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. reuse option ------------------------ If we did reuse the element, we would need to cater to the situation where: - need to provide SSL two way authentication for incoming connections (using both the and the elements) and - need to use the keystore to additionally store secret keys, public keys and private keys for ENCRYPT This could be achieved by: - sharing a single element between the incoming connections requiring SSL and JGroups peers joining a group - always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the element for both cases Some small problems: 1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the attribute provider="JCEKS". 2. The other problem here is that access to the service representing the keystore is not intended for public consumption. The element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore. Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do. use option ------------------------------- If we create a new element of to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT. Reuse of the element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity. was (Author: rachmato): Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm There are two issues: - configuration of SASL/ENCRYPT via existing security realm XML elements - accessing the configured security realm data from the associated services for injection into ENCRYPT existing security realm configuration --------------------------------------------- Relevant to this discussion, the security realm contains the following XML configuration elements: {code:xml} {code} where:: - the element is designed for setting up key material for an SSLContext for incoming remote connections - the element is designed for setting up key material for SSL two way authentication configuration: JGroups SASL layer -------------------------------------------- The existing SASL integration (in JDG) makes use of the configuration in . The JGroups SASL layer supports these mechanisms: ||SASL mechanism || SecurityRealm mechanism || CallbackHandler || | PLAIN | PLAIN | PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler| | DIGEST_MD5 | DIGEST | PropertiesCallbackHandler, UserDomainCallbackHandler | | GSSAPI | PLAIN | (see above)| |EXTERNAL | CLIENT_CERT | ClientCertCallbackHandler| where: - mechanism determines the way in which user data is handled/encoded between client and server - callback handler determines how the user data is actually obtained So, for example: - if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the or elements with user information - if we want to use the PLAIN mechanism, we should populate the , , or elements with user information In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs. configuration: JGroups ENCRYPT layer -------------------------------------------------- The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use: - symmetric encryption: a keystore for storing a single secret key - asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment) As we need a keystore for ENCRYPT usage, should we: - reuse the element for this purpose? - create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. reuse option ------------------------ If we did reuse the element, we would need to cater to the situation where: - need to provide SSL two way authentication for incoming connections (using both the and the elements) and - need to use the keystore to additionally store secret keys, public keys and private keys for ENCRYPT This could be achieved by: - sharing a single element between the incoming connections requiring SSL and JGroups peers joining a group - always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the element for both cases Some small problems: 1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the attribute provider="JCEKS". 2. The other problem here is that access to the service representing the keystore is not intended for public consumption. The element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore. Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do. use option ------------------------------- If we create a new element of to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT. Reuse of the element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity. > Integrate JGroups with core AS security infrastructure > ------------------------------------------------------ > > Key: WFLY-1067 > URL: https://issues.jboss.org/browse/WFLY-1067 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security > Reporter: Brian Stansberry > Assignee: Richard Achmatowicz > > Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components. > Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 21:12:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Wed, 19 Nov 2014 21:12:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4097) JAX-RS Returns Wrong Repsonse Code When A Method Is Not Allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shinzey shinzey updated WFLY-4097: ---------------------------------- Description: My RESTful service is protected with @RolesAllowed: {quote} @Stateless @RolesAllowed("admin") @Path("admin") {quote} When a non-admin user is trying to request this service, it fails with 500 Internal Server Error, instead of 403 Forbidden. From the log we can see that @RolesAllowed is working as expected: {quote} org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public zhyi.wildweb.AdminService zhyi.wildweb.AdminService.getUsers() of bean: AdminService is not allowed {quote} was: My RESTful service is protected with @RolesAllowed: {quote} @Stateless @RolesAllowed("admin") @Path("admin") {quote} When a non-admin user is trying to request this service, it fails with 500 Internal Server Error, instead of 401 Unauthorized. From the log we can see that @RolesAllowed is working as expected: {quote} org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public zhyi.wildweb.AdminService zhyi.wildweb.AdminService.getUsers() of bean: AdminService is not allowed {quote} > JAX-RS Returns Wrong Repsonse Code When A Method Is Not Allowed > --------------------------------------------------------------- > > Key: WFLY-4097 > URL: https://issues.jboss.org/browse/WFLY-4097 > Project: WildFly > Issue Type: Bug > Components: EJB, REST, Security > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: David Lloyd > Priority: Critical > > My RESTful service is protected with @RolesAllowed: > {quote} > @Stateless > @RolesAllowed("admin") > @Path("admin") > {quote} > When a non-admin user is trying to request this service, it fails with 500 Internal Server Error, instead of 403 Forbidden. From the log we can see that @RolesAllowed is working as expected: > {quote} > org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public zhyi.wildweb.AdminService zhyi.wildweb.AdminService.getUsers() of bean: AdminService is not allowed > {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 22:20:39 2014 From: issues at jboss.org (Jim Ma (JIRA)) Date: Wed, 19 Nov 2014 22:20:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-868) Multithread issues when validate with cached password + nonce credential info from JBossCachedAuthenticationManager In-Reply-To: References: Message-ID: Jim Ma created SECURITY-868: ------------------------------- Summary: Multithread issues when validate with cached password + nonce credential info from JBossCachedAuthenticationManager Key: SECURITY-868 URL: https://issues.jboss.org/browse/SECURITY-868 Project: PicketBox Issue Type: Task Components: PicketBox Reporter: Jim Ma Assignee: Stefan Guilhen When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 22:24:39 2014 From: issues at jboss.org (Jim Ma (JIRA)) Date: Wed, 19 Nov 2014 22:24:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached password + nonce credential info from JBossCachedAuthenticationManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Ma updated SECURITY-868: ---------------------------- Summary: Multithread issue when validate with cached password + nonce credential info from JBossCachedAuthenticationManager (was: Multithread issues when validate with cached password + nonce credential info from JBossCachedAuthenticationManager ) > Multithread issue when validate with cached password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 22:24:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Wed, 19 Nov 2014 22:24:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021398#comment-13021398 ] shinzey shinzey commented on WFLY-4096: --------------------------------------- Adding the hibernate.temp.use_jdbc_metadata_defaults property doesn't work. >From the log I guess that the persistence unit is created before binding the datasource, which might be the root cause. > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 22:24:40 2014 From: issues at jboss.org (Jim Ma (JIRA)) Date: Wed, 19 Nov 2014 22:24:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Ma updated SECURITY-868: ---------------------------- Summary: Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager (was: Multithread issue when validate with cached password + nonce credential info from JBossCachedAuthenticationManager ) > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 22:35:39 2014 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Wed, 19 Nov 2014 22:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4101) JAAS logout not called if cache-type is set to a value different than "default" In-Reply-To: References: Message-ID: Stefan Guilhen created WFLY-4101: ------------------------------------ Summary: JAAS logout not called if cache-type is set to a value different than "default" Key: WFLY-4101 URL: https://issues.jboss.org/browse/WFLY-4101 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 9.0.0.Alpha1 Reporter: Stefan Guilhen Assignee: Stefan Guilhen Fix For: 9.0.0.Beta1 Currently HttpServletRequest.logout() and Session.invalidate() rely on the AuthenticationManager.flushCache() method to perform the JAAS logout. Internally, flushCache() removes the cache entry and a cache listener takes care of the JAAS logout upon eviction. However, this is only true for cache-type="default". If the "inifinspan" cache is configured, no such eviction listener exists and thus no JAAS logout is carried upon entry removal. Similarly, a JAAS logout is never carried if the security domain doesn't use a cache at all. Only the presence of a cache with a special eviction listener will result in logout being called on the login module, which is obviously a faulty design. Latest PicketBox version adds a logout(Principal, Subject) method to the AuthenticationManager interface. The default implementation used by WildFly takes care of flushing the cache if needed and performs the JAAS logout independently of the cache policy being used. The code that is currently calling AuthenticationManager.flushCache() must be changed so that logout() is called instead. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 22:47:39 2014 From: issues at jboss.org (Jim Ma (JIRA)) Date: Wed, 19 Nov 2014 22:47:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021400#comment-13021400 ] Jim Ma commented on SECURITY-868: --------------------------------- I tried to look at cached credential info with key of username and nonce as we discussed. It seems there is large number of cached entry will be created for concurrent validation invocation : https://github.com/jimma/picketbox-1/commit/2817c1a9f8cab6d3fb8d83ad9cc59 I back to refactor JBossCachedAuthenticationManager change and sent proposed PR: https://github.com/picketbox/picketbox/pull/23 > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 22:48:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Wed, 19 Nov 2014 22:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shinzey shinzey updated WFLY-4096: ---------------------------------- Description: The datasource defined in web.xml: {quote} java:/datasources/test org.apache.derby.jdbc.ClientDataSource test jdbc:derby://localhost:1527/test test test {quote} The persistence unit: {quote} java:/datasources/test {quote} The deployment error: {quote} 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] {quote} If I remove the persistence unit, the datasource can be successfully bound: {quote} 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] {quote} The same code works as expected in GlassFish 4.1. was: The datasource defined in web.xml: {quote} java:/datasources/test org.apache.derby.jdbc.ClientDataSource test jdbc:derby://localhost:1527/test test test {quote} The persistence unit: {quote} java:/datasources/test {quote} The deployment error: {quote} 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] {quote} If I remove the persistence unit, the datasource can be successfully bound: {quote} 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] {quote} > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 22:48:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Wed, 19 Nov 2014 22:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021401#comment-13021401 ] shinzey shinzey commented on WFLY-4096: --------------------------------------- I just confirmed that the same code works as expected in GlassFish 4.1, so I think it's a WildFly bug. > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 19 23:40:39 2014 From: issues at jboss.org (Ron Sigal (JIRA)) Date: Wed, 19 Nov 2014 23:40:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBREM-1327) Fix synchronization in BlockingCallbackStore In-Reply-To: References: Message-ID: Ron Sigal created JBREM-1327: -------------------------------- Summary: Fix synchronization in BlockingCallbackStore Key: JBREM-1327 URL: https://issues.jboss.org/browse/JBREM-1327 Project: JBoss Remoting Issue Type: Bug Affects Versions: 2.5.4.SP5 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.4.SP6 In org.jboss.remoting.callback.BlockingCallbackStore, add() waits on a lock which is released only when getNext() is called. so a second Callback can be added only after the first is removed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 00:18:39 2014 From: issues at jboss.org (James Livingston (JIRA)) Date: Thu, 20 Nov 2014 00:18:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021403#comment-13021403 ] James Livingston commented on WFCORE-263: ----------------------------------------- Doing that works correctly. My understanding is that in this setup, there is a composite op running on the DC, a composite op running on the slave HC(s), and an op per server instance to do the undeployment. Cancelling the DC op works correctly, and tells the server instance to interrupt and it rolls back (obviously the web container thread to undeploy is still blocked). Cancelling the per-server op works correctly, as it triggers a rollback of the HC op and then DC op. If you cancel the HC op, it says it does so and the HC op disappears, but the per-server op looks like it is still running. Cancelling that per-server op gets it back to a working state. I'm not sure why, but it looks like if you tell it to cancel the HC-level op (rather than the DC op), it is not cancelling the per-server op. > Cancelling management op on slave HC tree is broken > --------------------------------------------------- > > Key: WFCORE-263 > URL: https://issues.jboss.org/browse/WFCORE-263 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha9 > Reporter: James Livingston > Assignee: Brian Stansberry > > If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via: > /host=master/core-service=management/service=management-operations:find-non-progressing-operation > /host=slave/core-service=management/service=management-operations:find-non-progressing-operation > Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. > If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. > Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. > Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 00:28:39 2014 From: issues at jboss.org (James Livingston (JIRA)) Date: Thu, 20 Nov 2014 00:28:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Livingston updated WFCORE-263: ------------------------------------ Attachment: unundeployable.zip > Cancelling management op on slave HC tree is broken > --------------------------------------------------- > > Key: WFCORE-263 > URL: https://issues.jboss.org/browse/WFCORE-263 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha9 > Reporter: James Livingston > Assignee: Brian Stansberry > Attachments: unundeployable.zip > > > If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via: > /host=master/core-service=management/service=management-operations:find-non-progressing-operation > /host=slave/core-service=management/service=management-operations:find-non-progressing-operation > Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. > If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. > Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. > Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 00:30:39 2014 From: issues at jboss.org (James Livingston (JIRA)) Date: Thu, 20 Nov 2014 00:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021404#comment-13021404 ] James Livingston commented on WFCORE-263: ----------------------------------------- I've attached a simple reproducer with an @Startup @Singleton EJB that block forever in it's @PreDestroy. To use: 1) build with maven 2) start the host-master and host-slave configurations we ship 3) Deploy it and assign to the main group which runs on the slave HC 4) Attempt to remove the deployment 5) Poke around in the CLI > Cancelling management op on slave HC tree is broken > --------------------------------------------------- > > Key: WFCORE-263 > URL: https://issues.jboss.org/browse/WFCORE-263 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha9 > Reporter: James Livingston > Assignee: Brian Stansberry > Attachments: unundeployable.zip > > > If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via: > /host=master/core-service=management/service=management-operations:find-non-progressing-operation > /host=slave/core-service=management/service=management-operations:find-non-progressing-operation > Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again. > If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive. > Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled. > Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 01:08:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Thu, 20 Nov 2014 01:08:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shinzey shinzey updated WFLY-4096: ---------------------------------- Description: The datasource defined in web.xml: {quote} java:/datasources/test org.apache.derby.jdbc.ClientDataSource test jdbc:derby://localhost:1527/test test test {quote} The persistence unit: {quote} java:/datasources/test {quote} The deployment error: {quote} 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] {quote} If I remove the persistence unit, the datasource can be successfully bound: {quote} 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] {quote} The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. was: The datasource defined in web.xml: {quote} java:/datasources/test org.apache.derby.jdbc.ClientDataSource test jdbc:derby://localhost:1527/test test test {quote} The persistence unit: {quote} java:/datasources/test {quote} The deployment error: {quote} 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] {quote} If I remove the persistence unit, the datasource can be successfully bound: {quote} 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] {quote} The same code works as expected in GlassFish 4.1. > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 01:09:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Thu, 20 Nov 2014 01:09:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021401#comment-13021401 ] shinzey shinzey edited comment on WFLY-4096 at 11/20/14 1:08 AM: ----------------------------------------------------------------- I just confirmed that the same code works as expected in GlassFish 4.1, so I think it's a WildFly bug. The @DataSourceDefinition annotation has the same issue in WildFly. was (Author: shinzey): I just confirmed that the same code works as expected in GlassFish 4.1, so I think it's a WildFly bug. > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 03:15:40 2014 From: issues at jboss.org (Ron Sigal (JIRA)) Date: Thu, 20 Nov 2014 03:15:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBREM-1327) Fix synchronization in BlockingCallbackStore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBREM-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021419#comment-13021419 ] Ron Sigal commented on JBREM-1327: ---------------------------------- Added configuration parameter org.jboss.remoting.callback.ServerInvokerCallbackHandler.CALLBACK_STORE_MAX_SIZE (actual value "callbackStoreMaxSize"), which determines the number of Callbacks can be held by org.jboss.remoting.callback.BlockingCallbackStore before add() blocks, waiting for getNext() to remove a Callback. Default value is 10000. Testing: org.jboss.test.remoting.callback.pull.memory.blocking.BlockingCallbackStoreSynchronizationTestCase. Changes committed to https://svn.jboss.org/repos/jbossremoting/remoting2/branches/2.5.4.SP4-01241076 > Fix synchronization in BlockingCallbackStore > -------------------------------------------- > > Key: JBREM-1327 > URL: https://issues.jboss.org/browse/JBREM-1327 > Project: JBoss Remoting > Issue Type: Bug > Affects Versions: 2.5.4.SP5 > Reporter: Ron Sigal > Assignee: Ron Sigal > Fix For: 2.5.4.SP6 > > > In org.jboss.remoting.callback.BlockingCallbackStore, add() waits on a lock which is released only when getNext() is called. so a second Callback can be added only after the first is removed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 03:15:40 2014 From: issues at jboss.org (Ron Sigal (JIRA)) Date: Thu, 20 Nov 2014 03:15:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBREM-1327) Fix synchronization in BlockingCallbackStore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBREM-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021419#comment-13021419 ] Ron Sigal edited comment on JBREM-1327 at 11/20/14 3:15 AM: ------------------------------------------------------------ Added configuration parameter org.jboss.remoting.callback.ServerInvokerCallbackHandler.CALLBACK_STORE_MAX_SIZE (actual value "callbackStoreMaxSize"), which determines the number of Callbacks that can be held by org.jboss.remoting.callback.BlockingCallbackStore before add() blocks, waiting for getNext() to remove a Callback. Default value is 10000. Testing: org.jboss.test.remoting.callback.pull.memory.blocking.BlockingCallbackStoreSynchronizationTestCase. Changes committed to https://svn.jboss.org/repos/jbossremoting/remoting2/branches/2.5.4.SP4-01241076 was (Author: ron_sigal): Added configuration parameter org.jboss.remoting.callback.ServerInvokerCallbackHandler.CALLBACK_STORE_MAX_SIZE (actual value "callbackStoreMaxSize"), which determines the number of Callbacks can be held by org.jboss.remoting.callback.BlockingCallbackStore before add() blocks, waiting for getNext() to remove a Callback. Default value is 10000. Testing: org.jboss.test.remoting.callback.pull.memory.blocking.BlockingCallbackStoreSynchronizationTestCase. Changes committed to https://svn.jboss.org/repos/jbossremoting/remoting2/branches/2.5.4.SP4-01241076 > Fix synchronization in BlockingCallbackStore > -------------------------------------------- > > Key: JBREM-1327 > URL: https://issues.jboss.org/browse/JBREM-1327 > Project: JBoss Remoting > Issue Type: Bug > Affects Versions: 2.5.4.SP5 > Reporter: Ron Sigal > Assignee: Ron Sigal > Fix For: 2.5.4.SP6 > > > In org.jboss.remoting.callback.BlockingCallbackStore, add() waits on a lock which is released only when getNext() is called. so a second Callback can be added only after the first is removed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 03:45:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 03:45:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3969) HeaderTokenParser doesn't parse correctly values which includes a quote In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021430#comment-13021430 ] RH Bugzilla Integration commented on WFLY-3969: ----------------------------------------------- Kabir Khan changed the Status of [bug 1150024|https://bugzilla.redhat.com/show_bug.cgi?id=1150024] from POST to MODIFIED > HeaderTokenParser doesn't parse correctly values which includes a quote > ----------------------------------------------------------------------- > > Key: WFLY-3969 > URL: https://issues.jboss.org/browse/WFLY-3969 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > Priority: Critical > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > The header parser doesn't work correctly if a parsed value contains quote character ("). The problem is, the parser is in phase of searching a LAST_QUOTE and it doesn't check if the found quote character is escaped or not. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 03:46:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 03:46:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021431#comment-13021431 ] RH Bugzilla Integration commented on WFLY-4089: ----------------------------------------------- Kabir Khan changed the Status of [bug 1164600|https://bugzilla.redhat.com/show_bug.cgi?id=1164600] from POST to MODIFIED > ServletContainerInitializerDeploymentProcessor does not handle comments > ----------------------------------------------------------------------- > > Key: WFLY-4089 > URL: https://issues.jboss.org/browse/WFLY-4089 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: James Livingston > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. > The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. > Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 03:49:39 2014 From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA)) Date: Thu, 20 Nov 2014 03:49:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBTEST-21) Intermittent fail of some datasource tests on IBM JDK of DataSourceOperationsUnitTestCase In-Reply-To: References: Message-ID: Panagiotis Sotiropoulos created JBTEST-21: --------------------------------------------- Summary: Intermittent fail of some datasource tests on IBM JDK of DataSourceOperationsUnitTestCase Key: JBTEST-21 URL: https://issues.jboss.org/browse/JBTEST-21 Project: JBoss Test Issue Type: Bug Environment: IBM JDK Reporter: Panagiotis Sotiropoulos Assignee: Panagiotis Sotiropoulos When test DataSourceOperationsUnitTestCase is build with IBM JDK 1.6 it fails with error : Tests in error: org.jboss.as.test.smoke.mgmt.datasource.DataSourceOperationsUnitTestCase: [SHRINKWRAP-93] Cannot use this JDK-based implementation to export as ZIP an archive with no content: 314225ff-6abf-4453-b69b-7dd12b707d65.jar: 0 assets Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 03:51:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 03:51:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBTEST-21) Intermittent fail of some datasource tests on IBM JDK of DataSourceOperationsUnitTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTEST-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBTEST-21: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1100839 > Intermittent fail of some datasource tests on IBM JDK of DataSourceOperationsUnitTestCase > ----------------------------------------------------------------------------------------- > > Key: JBTEST-21 > URL: https://issues.jboss.org/browse/JBTEST-21 > Project: JBoss Test > Issue Type: Bug > Environment: IBM JDK > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > When test DataSourceOperationsUnitTestCase is build with IBM JDK 1.6 it fails with error : > Tests in error: > org.jboss.as.test.smoke.mgmt.datasource.DataSourceOperationsUnitTestCase: [SHRINKWRAP-93] Cannot use this JDK-based implementation to export as ZIP an archive with no content: 314225ff-6abf-4453-b69b-7dd12b707d65.jar: 0 assets > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 04:01:39 2014 From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA)) Date: Thu, 20 Nov 2014 04:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBTEST-21) Intermittent fail DataSourceOperationsUnitTestCase on IBM JDK 1.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTEST-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Panagiotis Sotiropoulos updated JBTEST-21: ------------------------------------------ Summary: Intermittent fail DataSourceOperationsUnitTestCase on IBM JDK 1.6 (was: Intermittent fail of some datasource tests on IBM JDK of DataSourceOperationsUnitTestCase) > Intermittent fail DataSourceOperationsUnitTestCase on IBM JDK 1.6 > ----------------------------------------------------------------- > > Key: JBTEST-21 > URL: https://issues.jboss.org/browse/JBTEST-21 > Project: JBoss Test > Issue Type: Bug > Environment: IBM JDK > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > When test DataSourceOperationsUnitTestCase is build with IBM JDK 1.6 it fails with error : > Tests in error: > org.jboss.as.test.smoke.mgmt.datasource.DataSourceOperationsUnitTestCase: [SHRINKWRAP-93] Cannot use this JDK-based implementation to export as ZIP an archive with no content: 314225ff-6abf-4453-b69b-7dd12b707d65.jar: 0 assets > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 04:01:39 2014 From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA)) Date: Thu, 20 Nov 2014 04:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBTEST-21) Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTEST-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Panagiotis Sotiropoulos updated JBTEST-21: ------------------------------------------ Summary: Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 (was: Intermittent fail DataSourceOperationsUnitTestCase on IBM JDK 1.6) > Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 > -------------------------------------------------------------------- > > Key: JBTEST-21 > URL: https://issues.jboss.org/browse/JBTEST-21 > Project: JBoss Test > Issue Type: Bug > Environment: IBM JDK > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > When test DataSourceOperationsUnitTestCase is build with IBM JDK 1.6 it fails with error : > Tests in error: > org.jboss.as.test.smoke.mgmt.datasource.DataSourceOperationsUnitTestCase: [SHRINKWRAP-93] Cannot use this JDK-based implementation to export as ZIP an archive with no content: 314225ff-6abf-4453-b69b-7dd12b707d65.jar: 0 assets > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 04:04:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 04:04:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-643) Spreadsheet cell value by XLS function results in decimal fraction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021434#comment-13021434 ] RH Bugzilla Integration commented on DROOLS-643: ------------------------------------------------ Ryan Zhang changed the Status of [bug 1157319|https://bugzilla.redhat.com/show_bug.cgi?id=1157319] from MODIFIED to ON_QA > Spreadsheet cell value by XLS function results in decimal fraction > ------------------------------------------------------------------ > > Key: DROOLS-643 > URL: https://issues.jboss.org/browse/DROOLS-643 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.Beta1 > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Fix For: 6.2.0.CR2 > > > If you use XLS functions (e.g. =ROW(), =SUM()) in Spreadsheet cells, the values (e.g. '10') are parsed to decimal fraction values (e.g. '10.0'). This doesn't occur in version 5.3. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 04:04:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 04:04:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-576) NullPointerException in ActivationTimerInputMarshaller.deserialize() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021435#comment-13021435 ] RH Bugzilla Integration commented on DROOLS-576: ------------------------------------------------ Ryan Zhang changed the Status of [bug 1130404|https://bugzilla.redhat.com/show_bug.cgi?id=1130404] from MODIFIED to ON_QA > NullPointerException in ActivationTimerInputMarshaller.deserialize() > -------------------------------------------------------------------- > > Key: DROOLS-576 > URL: https://issues.jboss.org/browse/DROOLS-576 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Beta1 > Environment: RETEOO engine > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Fix For: 6.2.0.CR2 > > > With the following conditions: > - A persisted ksession > - RETEOO engine > - ksession is disposed while a timer is activated > - ksession is loaded with a new kbase which doesn't have a rule which associated with the timer > ActivationTimerInputMarshaller.deserialize() throws a NullPointerException so failed to load the ksession. > {noformat} > java.lang.RuntimeException: Unable to load session snapshot > at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:88) ~[classes/:na] > at org.drools.persistence.SingleSessionCommandService.initExistingKnowledgeSession(SingleSessionCommandService.java:239) ~[classes/:na] > at org.drools.persistence.SingleSessionCommandService.(SingleSessionCommandService.java:172) ~[classes/:na] > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [na:1.7.0_67] > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [na:1.7.0_67] > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [na:1.7.0_67] > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [na:1.7.0_67] > at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.buildCommandService(KnowledgeStoreServiceImpl.java:122) [classes/:na] > at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.loadKieSession(KnowledgeStoreServiceImpl.java:90) [classes/:na] > at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.loadKieSession(KnowledgeStoreServiceImpl.java:39) [classes/:na] > at org.kie.internal.persistence.jpa.JPAKnowledgeService.loadStatefulKnowledgeSession(JPAKnowledgeService.java:130) [kie-internal-6.2.0-SNAPSHOT.jar:6.2.0-SNAPSHOT] > at org.drools.persistence.timer.integrationtests.TimerAndCalendarTest.testTimerWithRemovingRule(TimerAndCalendarTest.java:340) [test-classes/:na] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_67] > ... > Caused by: java.lang.NullPointerException: null > at org.drools.core.common.Scheduler$ActivationTimerInputMarshaller.deserialize(Scheduler.java:216) ~[drools-core-6.2.0-SNAPSHOT.jar:6.2.0-SNAPSHOT] > at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readTimer(ProtobufInputMarshaller.java:700) ~[drools-core-6.2.0-SNAPSHOT.jar:6.2.0-SNAPSHOT] > at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:282) ~[drools-core-6.2.0-SNAPSHOT.jar:6.2.0-SNAPSHOT] > at org.drools.core.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:155) ~[drools-core-6.2.0-SNAPSHOT.jar:6.2.0-SNAPSHOT] > at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:110) ~[drools-core-6.2.0-SNAPSHOT.jar:6.2.0-SNAPSHOT] > at org.drools.core.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:54) ~[drools-core-6.2.0-SNAPSHOT.jar:6.2.0-SNAPSHOT] > at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:83) ~[classes/:na] > ... 44 common frames omitted > {noformat} > Probably we may silently ignore the timer when leftTuple is not found. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 04:37:39 2014 From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA)) Date: Thu, 20 Nov 2014 04:37:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBTEST-21) Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTEST-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021454#comment-13021454 ] Panagiotis Sotiropoulos commented on JBTEST-21: ----------------------------------------------- PR sent : Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 > Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 > -------------------------------------------------------------------- > > Key: JBTEST-21 > URL: https://issues.jboss.org/browse/JBTEST-21 > Project: JBoss Test > Issue Type: Bug > Environment: IBM JDK > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > When test DataSourceOperationsUnitTestCase is build with IBM JDK 1.6 it fails with error : > Tests in error: > org.jboss.as.test.smoke.mgmt.datasource.DataSourceOperationsUnitTestCase: [SHRINKWRAP-93] Cannot use this JDK-based implementation to export as ZIP an archive with no content: 314225ff-6abf-4453-b69b-7dd12b707d65.jar: 0 assets > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 04:37:39 2014 From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA)) Date: Thu, 20 Nov 2014 04:37:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBTEST-21) Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTEST-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021454#comment-13021454 ] Panagiotis Sotiropoulos edited comment on JBTEST-21 at 11/20/14 4:37 AM: ------------------------------------------------------------------------- PR sent : https://github.com/jbossas/jboss-eap/pull/1998 was (Author: takis): PR sent : Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 > Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 > -------------------------------------------------------------------- > > Key: JBTEST-21 > URL: https://issues.jboss.org/browse/JBTEST-21 > Project: JBoss Test > Issue Type: Bug > Environment: IBM JDK > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > When test DataSourceOperationsUnitTestCase is build with IBM JDK 1.6 it fails with error : > Tests in error: > org.jboss.as.test.smoke.mgmt.datasource.DataSourceOperationsUnitTestCase: [SHRINKWRAP-93] Cannot use this JDK-based implementation to export as ZIP an archive with no content: 314225ff-6abf-4453-b69b-7dd12b707d65.jar: 0 assets > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 04:39:39 2014 From: issues at jboss.org (Panagiotis Sotiropoulos (JIRA)) Date: Thu, 20 Nov 2014 04:39:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBTEST-21) Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTEST-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Panagiotis Sotiropoulos closed JBTEST-21. ----------------------------------------- Resolution: Done > Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 > -------------------------------------------------------------------- > > Key: JBTEST-21 > URL: https://issues.jboss.org/browse/JBTEST-21 > Project: JBoss Test > Issue Type: Bug > Environment: IBM JDK > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > When test DataSourceOperationsUnitTestCase is build with IBM JDK 1.6 it fails with error : > Tests in error: > org.jboss.as.test.smoke.mgmt.datasource.DataSourceOperationsUnitTestCase: [SHRINKWRAP-93] Cannot use this JDK-based implementation to export as ZIP an archive with no content: 314225ff-6abf-4453-b69b-7dd12b707d65.jar: 0 assets > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 04:51:39 2014 From: issues at jboss.org (Tom Fonteyne (JIRA)) Date: Thu, 20 Nov 2014 04:51:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3688) datasources subsystem: xa-datasource properties doe not support the use of multiple values for one property In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021462#comment-13021462 ] Tom Fonteyne commented on WFLY-3688: ------------------------------------ Sybase JDBC driver has this as well: setConnectionProperties(java.util.Properties value) > datasources subsystem: xa-datasource properties doe not support the use of multiple values for one property > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-3688 > URL: https://issues.jboss.org/browse/WFLY-3688 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.1.0.Final > Reporter: Tom Fonteyne > Assignee: Stefano Maestri > > The oracle JDBC driver had a method: > setConnectionProperties(java.util.Properties value) > which is needed to set several connection properties for datasources. > Most (all?) of these connection properties do not have individual setters. > WildFly does not support setting a "Properties" value for "xa-datasource-property" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 05:20:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 05:20:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021472#comment-13021472 ] RH Bugzilla Integration commented on WFLY-4089: ----------------------------------------------- Ivo Studensky changed the Status of [bug 1165967|https://bugzilla.redhat.com/show_bug.cgi?id=1165967] from NEW to POST > ServletContainerInitializerDeploymentProcessor does not handle comments > ----------------------------------------------------------------------- > > Key: WFLY-4089 > URL: https://issues.jboss.org/browse/WFLY-4089 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: James Livingston > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. > The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. > Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 06:02:39 2014 From: issues at jboss.org (Pavel Janousek (JIRA)) Date: Thu, 20 Nov 2014 06:02:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-645) Implement fallback mechanism for AS7 properties in pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Janousek closed WFLY-645. ------------------------------- Resolution: Out of Date > Implement fallback mechanism for AS7 properties in pom.xml > ---------------------------------------------------------- > > Key: WFLY-645 > URL: https://issues.jboss.org/browse/WFLY-645 > Project: WildFly > Issue Type: Sub-task > Components: Test Suite > Reporter: Pavel Janousek > Assignee: Pavel Janousek > > There are several places where is used fallback mechanism when some content from property is taken like:{code}static final String someIPproperty = System.getProperty(" key>", "localhost");{code} > The final decision based on (linked) AS7 devel discussion is leaving this approach and set-up this things in pom.xml's only. > After this task will be done, old approach will be leaved at all and every new patch will be forced to not use/include a such fallback mechanism only. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 06:21:40 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Thu, 20 Nov 2014 06:21:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-226) automatical modification of class and method Annotation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shigeru Chiba closed JASSIST-226. --------------------------------- Resolution: Rejected OK, this is a wrong API usage. The correct code is: AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag); Annotation annot = new Annotation("RDFBean", constpool); annot.addMemberValue("value", new StringMemberValue("http://www...", constpool)); attr.addAnnotation(annot); An annotation member must be separately added. See the javadoc comment of AnnotationAttribute. > automatical modification of class and method Annotation > ------------------------------------------------------- > > Key: JASSIST-226 > URL: https://issues.jboss.org/browse/JASSIST-226 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.18.0-GA > Environment: JavaSE-1.7, Eclipse Kepler > Reporter: Paolo Paolo > Assignee: Shigeru Chiba > Labels: annotations > > I'm using Javassist to create .class file at runtime. Every method of the created class must have a Java Annotation ("@annotation example") with an URI. The problem is that the Annotation class modifies automatically the URI by substituting slashes with dots. > //the Annotation String that I need > @RDFBean('http://www.semanticweb.org/pi/2014/5/test#Test') > //the resulting String > @RDFBean('http:..www.semanticweb.org.pi.2014.5.test#Test') > Is there a way to prevent this String modification? > I suppose it's related to the different notation between a file path and a Java package. > This is the code: > ClassPool pool = ClassPool.getDefault(); > CtClass cc = pool.makeClass(className); > > ClassFile ccFile = cc.getClassFile(); > ConstPool constpool = ccFile.getConstPool(); > // create the annotation > AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag); > // classLocalName contains: http://www.semanticweb.org/pi/2014/5/test#Test > Annotation annot = new Annotation("RDFBean('" + classLocalName + "')", constpool); > attr.addAnnotation(annot); > ccFile.addAttribute(attr); -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 06:27:40 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Thu, 20 Nov 2014 06:27:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-222) Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shigeru Chiba closed JASSIST-222. --------------------------------- Resolution: Won't Fix OK, I close this issue because it would be impossible to fix this problem. In the bytecode generated by Jikes, there is not a position where a constructor call has been done but the execution of the constructor body has not started. As we see in the bytecode, when the constructor call is executed, the execution of the constructor body has been already started. So there is no position we can safely insert a try-catch statement at somewhere "just after a constructor call". > Using insertBeforeBody to insert try/catch block in constructor can generate invalid bytecode for certain Java compilers > ------------------------------------------------------------------------------------------------------------------------ > > Key: JASSIST-222 > URL: https://issues.jboss.org/browse/JASSIST-222 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.18.0-GA > Environment: Unknown java compiler generating class files with major version 45, minor version 3. > Mint Linux, JDK 1.7. > Reporter: Manuel Geffken > Assignee: Shigeru Chiba > Priority: Minor > Attachments: S.class, S.java, S_instr_error.class, S_instr_success.class > > > The class S in the "boyer" benchmark of the Ashes Suite Collection (http://www.sable.mcgill.ca/ashes/) (no original source code available) has the following bytecode according to javap: > {noformat} > Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/classes/S.class > Last modified May 2, 2014; size 154 bytes > MD5 checksum e79a1481a39d40004bc504cc4f7c2641 > class S > minor version: 3 > major version: 45 > flags: ACC_SUPER > Constant pool: > ... > { > protected int $; > flags: ACC_PROTECTED > protected S(int); > flags: ACC_PROTECTED > Code: > stack=3, locals=2, args_size=2 > 0: aload_0 > 1: iload_1 > 2: aload_0 > 3: invokespecial #14 // Method java/lang/Object."":()V > 6: putfield #13 // Field $:I > 9: return > } > {noformat} > An instrumentation of this class' constructor with a try/catch block as in > {noformat} > CtConstructor[] ctors = target.getDeclaredConstructors(); > for (CtConstructor ctor : ctors) { > StringBuilder headerSB = new StringBuilder(); > headerSB.append("{"); > headerSB.append(" try {"); > headerSB.append(" throw new java.lang.Exception();"); > headerSB.append(" } catch(java.lang.Exception e) {}"); > headerSB.append("}"); > ctor.insertBeforeBody(headerSB.toString()); > } > {noformat} > causes an invalid class file that _does not verify_: > {noformat} > Classfile ashesSuiteCollection/suites/ashesHardTestSuite/benchmarks/boyer/out_classes/S_instr_error.class > Last modified May 5, 2014; size 356 bytes > MD5 checksum d4ef556ee82cee6c4c2960b43d7e71e1 > class S > minor version: 3 > major version: 45 > flags: ACC_SUPER > Constant pool: > ... > { > protected int $; > flags: ACC_PROTECTED > protected S(int); > flags: ACC_PROTECTED > Code: > stack=5, locals=3, args_size=2 > 0: aload_0 > 1: iload_1 > 2: aload_0 > 3: invokespecial #14 // Method java/lang/Object."":()V > 6: new #22 // class java/lang/Exception > 9: dup > 10: invokespecial #23 // Method java/lang/Exception."":()V > 13: athrow > 14: astore_2 > 15: goto 18 > 18: putfield #13 // Field $:I > 21: return > Exception table: > from to target type > 6 14 14 Class java/lang/Exception > } > {noformat} > The problem is that the operand stack can be empty when the {{putfield}} instruction is reached. The problem seems to be rooted in the fact that the original bytecode sequence assumes that the two entries of the operand stack reach the {{putfield}} instruction. However, this assumption is invalid in the instrumented code. > In contrast the reconstructed source code (the original source is not available) > {noformat} > class S { > int $; > > public S(int i) { > $ = i; > } > } > {noformat} > compiled with javac 1.7.0_51 ({{javac -source 1.3 -target 1.1}}) produces > {noformat} > Classfile S.class > Last modified May 5, 2014; size 222 bytes > MD5 checksum 9700e6458db9d62e640018421a079761 > Compiled from "S.java" > public class S > SourceFile: "S.java" > minor version: 3 > major version: 45 > flags: ACC_SUPER > Constant pool: > ... > { > int $; > flags: > public S(int); > flags: ACC_PUBLIC > Code: > stack=2, locals=2, args_size=2 > 0: aload_0 > 1: invokespecial #1 // Method java/lang/Object."":()V > 4: aload_0 > 5: iload_1 > 6: putfield #2 // Field $:I > 9: return > } > {noformat} > This version can be instrumented as shown above without problems. Here the operand of the putfield instruction are pushed on the stack _after_ the {{invokespecial}} instruction. > {noformat} > 1: invokespecial #1 // Method java/lang/Object."":()V > 4: aload_0 > 5: iload_1 > {noformat} > This sequence seems easier to instrument (after the super call) with code containing a try/catch block. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 06:51:39 2014 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Thu, 20 Nov 2014 06:51:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4102) CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases In-Reply-To: References: Message-ID: Tomas Hofman created WFLY-4102: ---------------------------------- Summary: CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases Key: WFLY-4102 URL: https://issues.jboss.org/browse/WFLY-4102 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: 9.0.0.Alpha1 Reporter: Tomas Hofman Assignee: Tomas Hofman This is copy of https://bugzilla.redhat.com/show_bug.cgi?id=1149099 Description: The CLI freezes in phase of requesting username/password in some cases. Reproducer ========== Run following command: ./jboss-cli.sh -c << EOF /core-service=management/security-realm=ManagementRealm/authentication=local:remove reload EOF -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 06:54:39 2014 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Thu, 20 Nov 2014 06:54:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-269) CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hofman moved WFLY-4102 to WFCORE-269: ------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-269 (was: WFLY-4102) Affects Version/s: (was: 9.0.0.Alpha1) Component/s: CLI (was: CLI) > CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases > ------------------------------------------------------------------------------- > > Key: WFCORE-269 > URL: https://issues.jboss.org/browse/WFCORE-269 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > This is copy of https://bugzilla.redhat.com/show_bug.cgi?id=1149099 > Description: > The CLI freezes in phase of requesting username/password in some cases. > Reproducer > ========== > Run following command: > ./jboss-cli.sh -c << EOF > /core-service=management/security-realm=ManagementRealm/authentication=local:remove > reload > EOF -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 06:55:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 06:55:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-269) CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-269: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1149099 > CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases > ------------------------------------------------------------------------------- > > Key: WFCORE-269 > URL: https://issues.jboss.org/browse/WFCORE-269 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > This is copy of https://bugzilla.redhat.com/show_bug.cgi?id=1149099 > Description: > The CLI freezes in phase of requesting username/password in some cases. > Reproducer > ========== > Run following command: > ./jboss-cli.sh -c << EOF > /core-service=management/security-realm=ManagementRealm/authentication=local:remove > reload > EOF -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 06:56:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 06:56:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-269) CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021527#comment-13021527 ] RH Bugzilla Integration commented on WFCORE-269: ------------------------------------------------ Tomas Hofman changed the Status of [bug 1149099|https://bugzilla.redhat.com/show_bug.cgi?id=1149099] from ASSIGNED to POST > CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases > ------------------------------------------------------------------------------- > > Key: WFCORE-269 > URL: https://issues.jboss.org/browse/WFCORE-269 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > This is copy of https://bugzilla.redhat.com/show_bug.cgi?id=1149099 > Description: > The CLI freezes in phase of requesting username/password in some cases. > Reproducer > ========== > Run following command: > ./jboss-cli.sh -c << EOF > /core-service=management/security-realm=ManagementRealm/authentication=local:remove > reload > EOF -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 07:08:39 2014 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Thu, 20 Nov 2014 07:08:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-269) CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021535#comment-13021535 ] Tomas Hofman commented on WFCORE-269: ------------------------------------- PR: https://github.com/wildfly/wildfly-core/pull/351 > CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases > ------------------------------------------------------------------------------- > > Key: WFCORE-269 > URL: https://issues.jboss.org/browse/WFCORE-269 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > This is copy of https://bugzilla.redhat.com/show_bug.cgi?id=1149099 > Description: > The CLI freezes in phase of requesting username/password in some cases. > Reproducer > ========== > Run following command: > ./jboss-cli.sh -c << EOF > /core-service=management/security-realm=ManagementRealm/authentication=local:remove > reload > EOF -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 07:57:39 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 20 Nov 2014 07:57:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4103) Upgrade HAL to 2.4.7.Final In-Reply-To: References: Message-ID: Harald Pehl created WFLY-4103: --------------------------------- Summary: Upgrade HAL to 2.4.7.Final Key: WFLY-4103 URL: https://issues.jboss.org/browse/WFLY-4103 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 8.2.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 07:57:39 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 20 Nov 2014 07:57:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4103) Upgrade HAL to 2.4.8.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4103: ------------------------------ Summary: Upgrade HAL to 2.4.8.Final (was: Upgrade HAL to 2.4.7.Final) > Upgrade HAL to 2.4.8.Final > -------------------------- > > Key: WFLY-4103 > URL: https://issues.jboss.org/browse/WFLY-4103 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 07:57:39 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 20 Nov 2014 07:57:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4104) Upgrade HAL to 2.4.8.Final In-Reply-To: References: Message-ID: Harald Pehl created WFLY-4104: --------------------------------- Summary: Upgrade HAL to 2.4.8.Final Key: WFLY-4104 URL: https://issues.jboss.org/browse/WFLY-4104 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 07:57:40 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 20 Nov 2014 07:57:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4103) Upgrade HAL to 2.4.8.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4103: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6950) > Upgrade HAL to 2.4.8.Final > -------------------------- > > Key: WFLY-4103 > URL: https://issues.jboss.org/browse/WFLY-4103 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 07:57:40 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 20 Nov 2014 07:57:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4104) Upgrade HAL to 2.4.8.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4104: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6949) > Upgrade HAL to 2.4.8.Final > -------------------------- > > Key: WFLY-4104 > URL: https://issues.jboss.org/browse/WFLY-4104 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 08:49:39 2014 From: issues at jboss.org (Rune Steinseth (JIRA)) Date: Thu, 20 Nov 2014 08:49:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3529) UT000010: Session not found In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021593#comment-13021593 ] Rune Steinseth commented on WFLY-3529: -------------------------------------- We have a problem that can be related to this error. In our case, after running with several users for a while, users start to get the session of another logged in user. On a server that has turned into a certain state, I can sit an press F5 in the browser and see that the logged in user changes for each request, having a certain affinity to the actual user I am logged in as. Before this happens, we see the "session not found" exception in the log: {code} [Server:frontend-server] 13:04:28,252 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-1) Error Rendering View[/secure/counting/counting.xhtml]: java.lang.IllegalStateException: UT000010: Session not found oc798wFrPPxqCCxrPtcJ8Hiw [Server:frontend-server]  at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:319) [undertow-core-1.0.15.Final.jar:1.0.15.Final] [Server:frontend-server]  at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] [Server:frontend-server]  at com.sun.faces.context.SessionMap.put(SessionMap.java:127) [jsf-impl-2.2.6-jbossorg-4.jar:] [Server:frontend-server]  at com.sun.faces.context.SessionMap.put(SessionMap.java:61) [jsf-impl-2.2.6-jbossorg-4.jar:] {code} We struggle to reproduce this. We have seen it sometimes in our local development environments, but it is not easy to reproduce, even when if we run capybara scripts with several logged in users in parallell. It tend to happen when we have meetings with the end users of the system and they run through different scenarios. Two observations: - it happens after lunch. Could it be related to session timeouts? - it happens when the end users are testing part of the system that haven't been tested thoroughly earlier and thus contains a lot of bugs. A lot of exceptions are thrown. Can the problem be related to exceptions not being handled correctly? > UT000010: Session not found > ---------------------------- > > Key: WFLY-3529 > URL: https://issues.jboss.org/browse/WFLY-3529 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Environment: Wildfly 8.1.0.Final , > Reporter: Youssef BIKHCHICHE > Assignee: Stuart Douglas > Attachments: WFLY-3529.tar.gz, WFLY-3529.war > > > After migration our AS from Woldfly 8.0.0 to 8.1.0 we get this issue that we think has been fixed in the previous release of wildfly. > ERREOR code : > 2014-06-20 12:45:21,092 ERROR [io.undertow.request] (default task-11) Blocking request failed HttpServerExchange{ GET /xenturion/faces/public/500.xhtml}: java.lang.RuntimeException: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:408) > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:311) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:128) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te > at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:319) > at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121) > at org.springframework.security.web.context.HttpSessionSecurityContextRepository.readSecurityContextFromSession(HttpSessionSecurityContextRepository.java:144) > at org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:86) > at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) > at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) > at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343) > at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172) > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:402) > ====================================================== > this issue happens after a http session invalidate action and it' not a regular problems. > Best regards, > Youssef -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 08:59:39 2014 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Thu, 20 Nov 2014 08:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021596#comment-13021596 ] Scott Marlow commented on WFLY-4096: ------------------------------------ Too bad hibernate.temp.use_jdbc_metadata_defaults doesn't help. Yeah, @DataSourceDefinition has the same issue (the DataSource isn't started until very late in deployment). In your persistence unit, try setting wildfly.jpa.twophasebootstrap to "false". > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 08:59:39 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Thu, 20 Nov 2014 08:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-208) current code size info should be available in ClassFileWriter.MethodWriter In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shigeru Chiba closed JASSIST-208. --------------------------------- Fix Version/s: 3.19.0-GA Resolution: Done > current code size info should be available in ClassFileWriter.MethodWriter > --------------------------------------------------------------------------- > > Key: JASSIST-208 > URL: https://issues.jboss.org/browse/JASSIST-208 > Project: Javassist > Issue Type: Feature Request > Reporter: Anton Danilov > Assignee: Shigeru Chiba > Fix For: 3.19.0-GA > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 09:21:40 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Thu, 20 Nov 2014 09:21:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek reopened WFLY-3651: ------------------------------- > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: wfly3651.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 09:22:40 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Thu, 20 Nov 2014 09:22:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3651) permissions.xml is not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josef Cacek resolved WFLY-3651. ------------------------------- Resolution: Done Probably fixed by https://github.com/wildfly/wildfly-core/pull/337 > permissions.xml is not used > --------------------------- > > Key: WFLY-3651 > URL: https://issues.jboss.org/browse/WFLY-3651 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Affects Versions: 8.1.0.Final > Environment: Fedora 20, jdk1.7.0_60 > Reporter: Ondrej Kotek > Assignee: David Lloyd > Priority: Blocker > Attachments: wfly3651.war > > > With security manager turned on, an application cannot use permissions allowed by permissions.xml configuration -- against EE 7 specification. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 09:59:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 09:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-187) cli deployment-overlay --redeploy-affected should check subdeployments as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021617#comment-13021617 ] RH Bugzilla Integration commented on WFCORE-187: ------------------------------------------------ Alexey Loubyansky changed the Status of [bug 1151435|https://bugzilla.redhat.com/show_bug.cgi?id=1151435] from NEW to POST > cli deployment-overlay --redeploy-affected should check subdeployments as well > ------------------------------------------------------------------------------ > > Key: WFCORE-187 > URL: https://issues.jboss.org/browse/WFCORE-187 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 1.0.0.Alpha11 > > > The redeploy-affected action of the deployment-overlay command checks only the top level deployments, although the changes sent by the command might have actually affected some subdeployments that won't be automatically redeployed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 09:59:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 09:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3999) cli deployment-overlay --redeploy-affected should check subdeployments as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021618#comment-13021618 ] RH Bugzilla Integration commented on WFLY-3999: ----------------------------------------------- Alexey Loubyansky changed the Status of [bug 1151435|https://bugzilla.redhat.com/show_bug.cgi?id=1151435] from NEW to POST > cli deployment-overlay --redeploy-affected should check subdeployments as well > ------------------------------------------------------------------------------ > > Key: WFLY-3999 > URL: https://issues.jboss.org/browse/WFLY-3999 > Project: WildFly > Issue Type: Enhancement > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 9.0.0.Beta1 > > > This issue has to be fixed in wildfly-core but the overlay tests are in the WildFly testsuite. This issue is for the tests covering this issue in WildFly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 10:14:39 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Thu, 20 Nov 2014 10:14:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1237) IronJacamar 1.0.30.Final In-Reply-To: References: Message-ID: Jesper Pedersen created JBJCA-1237: -------------------------------------- Summary: IronJacamar 1.0.30.Final Key: JBJCA-1237 URL: https://issues.jboss.org/browse/JBJCA-1237 Project: IronJacamar Issue Type: Release Components: Build Reporter: Jesper Pedersen Assignee: Jesper Pedersen Fix For: 1.0.30.Final Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12325980 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 10:27:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 10:27:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021643#comment-13021643 ] RH Bugzilla Integration commented on WFCORE-213: ------------------------------------------------ Kabir Khan changed the Status of [bug 1018026|https://bugzilla.redhat.com/show_bug.cgi?id=1018026] from POST to MODIFIED > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14, 1.0.0.Beta1 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 10:27:41 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Thu, 20 Nov 2014 10:27:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1237) IronJacamar 1.0.30.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesper Pedersen resolved JBJCA-1237. ------------------------------------ Resolution: Done > IronJacamar 1.0.30.Final > ------------------------ > > Key: JBJCA-1237 > URL: https://issues.jboss.org/browse/JBJCA-1237 > Project: IronJacamar > Issue Type: Release > Components: Build > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: 1.0.30.Final > > > Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12325980 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 10:47:39 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Thu, 20 Nov 2014 10:47:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-209) Nested classes read from ClassMemberValue cannot be loaded In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shigeru Chiba closed JASSIST-209. --------------------------------- Fix Version/s: 3.19.0-GA Resolution: Done > Nested classes read from ClassMemberValue cannot be loaded > ---------------------------------------------------------- > > Key: JASSIST-209 > URL: https://issues.jboss.org/browse/JASSIST-209 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.18.0-GA, 3.18.1-GA > Reporter: Ben Romberg > Assignee: Shigeru Chiba > Fix For: 3.19.0-GA > > > I'm trying to upgrade Javassist in my project from version 3.16.1 to 3.18.0. I'm using the ClassMemberValue to load the (String) class-name of an annotation value, in order to load the class with Javassist using ClassPool.get(...). > In 3.16.1, the returned class-name String for nested classes contained the $-sign, as in package.ParentClass$NestedClass, which didn't have any issues using the String with ClassPool.get(...). > In 3.18.0 however, the returned class-name String for nested classes changed to a pure dot-notation, as in package.ParentClass.NestedClass, which cannot be used with ClassPool.get(...) anymore, as Javassist tries to load the class-file from package/ParentClass/NestedClass.class instead of package/ParentClass$NestedClass.class. > I don't see any way to work around the issue without hacking into internal API, as the class-name String is the only way to get the annotation value. As this is a generic class (and not always a nested class), I also cannot simply replace the last dot with a $-sign. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 11:21:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 11:21:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-145) CLI run-batch command cannot process files with comments or blank lines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021668#comment-13021668 ] RH Bugzilla Integration commented on WFCORE-145: ------------------------------------------------ Alexey Loubyansky changed the Status of [bug 1148642|https://bugzilla.redhat.com/show_bug.cgi?id=1148642] from NEW to POST > CLI run-batch command cannot process files with comments or blank lines > ----------------------------------------------------------------------- > > Key: WFCORE-145 > URL: https://issues.jboss.org/browse/WFCORE-145 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha8 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > In the JBoss CLI tool, the "run-batch --file=script.cli" command cannot > successfully process lines that start with "#" or blank lines. Comments and > blank lines help readability when creating cli batch scripts. > However, running the batch file containing comments/blank lines as a parameter > to jboss-cli.sh works just fine (./jboss-cli.sh -c --file=script.cli). This > difference in accepted syntax creates some confusion for users who are new to > the CLI tool. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 11:23:40 2014 From: issues at jboss.org (Rune Steinseth (JIRA)) Date: Thu, 20 Nov 2014 11:23:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3529) UT000010: Session not found In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021593#comment-13021593 ] Rune Steinseth edited comment on WFLY-3529 at 11/20/14 11:23 AM: ----------------------------------------------------------------- We have a problem that can be related to this error. In our case, after running with several users for a while, users start to get the session of another logged in user. On a server that has turned into a certain state, I can sit an press F5 in the browser and see that the logged in user changes for each request, having a certain affinity to the actual user I am logged in as. Before this happens, we see the "session not found" exception in the log: {code} [Server:frontend-server] 13:04:28,252 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-1) Error Rendering View[/secure/counting/counting.xhtml]: java.lang.IllegalStateException: UT000010: Session not found oc798wFrPPxqCCxrPtcJ8Hiw [Server:frontend-server]  at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:319) [undertow-core-1.0.15.Final.jar:1.0.15.Final] [Server:frontend-server]  at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] [Server:frontend-server]  at com.sun.faces.context.SessionMap.put(SessionMap.java:127) [jsf-impl-2.2.6-jbossorg-4.jar:] [Server:frontend-server]  at com.sun.faces.context.SessionMap.put(SessionMap.java:61) [jsf-impl-2.2.6-jbossorg-4.jar:] {code} We struggle to reproduce this. We have seen it sometimes in our local development environments, but it is not easy to reproduce, even when we run capybara scripts with several logged in users in parallel. It tend to happen when we have meetings with the end users of the system and they run through different scenarios. Two observations: - it happens after lunch. Could it be related to session timeouts? - it happens when the end users are testing part of the system that haven't been tested thoroughly earlier and thus contains a lot of bugs. A lot of exceptions are thrown. Can the problem be related to exceptions not being handled correctly? Environment: WildFly 8.1.0-Final, Primefaces 5.0.8 was (Author: runeks2): We have a problem that can be related to this error. In our case, after running with several users for a while, users start to get the session of another logged in user. On a server that has turned into a certain state, I can sit an press F5 in the browser and see that the logged in user changes for each request, having a certain affinity to the actual user I am logged in as. Before this happens, we see the "session not found" exception in the log: {code} [Server:frontend-server] 13:04:28,252 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (default task-1) Error Rendering View[/secure/counting/counting.xhtml]: java.lang.IllegalStateException: UT000010: Session not found oc798wFrPPxqCCxrPtcJ8Hiw [Server:frontend-server]  at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:319) [undertow-core-1.0.15.Final.jar:1.0.15.Final] [Server:frontend-server]  at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] [Server:frontend-server]  at com.sun.faces.context.SessionMap.put(SessionMap.java:127) [jsf-impl-2.2.6-jbossorg-4.jar:] [Server:frontend-server]  at com.sun.faces.context.SessionMap.put(SessionMap.java:61) [jsf-impl-2.2.6-jbossorg-4.jar:] {code} We struggle to reproduce this. We have seen it sometimes in our local development environments, but it is not easy to reproduce, even when if we run capybara scripts with several logged in users in parallell. It tend to happen when we have meetings with the end users of the system and they run through different scenarios. Two observations: - it happens after lunch. Could it be related to session timeouts? - it happens when the end users are testing part of the system that haven't been tested thoroughly earlier and thus contains a lot of bugs. A lot of exceptions are thrown. Can the problem be related to exceptions not being handled correctly? > UT000010: Session not found > ---------------------------- > > Key: WFLY-3529 > URL: https://issues.jboss.org/browse/WFLY-3529 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Environment: Wildfly 8.1.0.Final , > Reporter: Youssef BIKHCHICHE > Assignee: Stuart Douglas > Attachments: WFLY-3529.tar.gz, WFLY-3529.war > > > After migration our AS from Woldfly 8.0.0 to 8.1.0 we get this issue that we think has been fixed in the previous release of wildfly. > ERREOR code : > 2014-06-20 12:45:21,092 ERROR [io.undertow.request] (default task-11) Blocking request failed HttpServerExchange{ GET /xenturion/faces/public/500.xhtml}: java.lang.RuntimeException: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:408) > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:311) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:128) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te > at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:319) > at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121) > at org.springframework.security.web.context.HttpSessionSecurityContextRepository.readSecurityContextFromSession(HttpSessionSecurityContextRepository.java:144) > at org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:86) > at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) > at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) > at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343) > at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172) > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:402) > ====================================================== > this issue happens after a http session invalidate action and it' not a regular problems. > Best regards, > Youssef -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 11:26:39 2014 From: issues at jboss.org (Michael Anstis (JIRA)) Date: Thu, 20 Nov 2014 11:26:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-649) Complex Dependencies Cause In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Anstis resolved DROOLS-649. ----------------------------------- Fix Version/s: 6.2.0.CR3 Resolution: Done > Complex Dependencies Cause > --------------------------- > > Key: DROOLS-649 > URL: https://issues.jboss.org/browse/DROOLS-649 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Environment: Drools 6.1.0, WildFly 8.1, JDK 1.7 > Reporter: Patrick Thomas > Assignee: Michael Anstis > Labels: dependency, kie > Fix For: 6.2.0.CR3 > > > When I add a dependency to my project that has other dependencies, KIE fills up my log file with multiple warnings and errors. See the forum reference for a sampling of messages I am receiving. One single reference filled my log file with 8MB of messages. > KIE appears to attempt to load every dependency of my dependency, and every dependency of those dependencies, and so on. The system becomes unusable for a while. After the scan is done, my Type drop down in the Data Modeler is filled with so many classes that it is difficult to find what I need. > The last problem (not mentioned in the forum) is that I can't shut down WildFly. I seem to get stuck in an endless loop with the following message being displayed repeatedly: > 13:41:55,522 WARN [org.jbpm.executor.impl.ExecutorRunnable] (pool-14-thread-1) Error while executing jobs due to {}null > It's possible that WildFly would eventually shut down, but I end up stopping the task forcibly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 11:27:39 2014 From: issues at jboss.org (Michael Anstis (JIRA)) Date: Thu, 20 Nov 2014 11:27:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-649) Complex Dependencies Cause In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021670#comment-13021670 ] Michael Anstis commented on DROOLS-649: --------------------------------------- Please raise a different JIRA for jBPM (https://issues.jboss.org/browse/JBPM) for the new issue you've tagged on to the end. Thank-you > Complex Dependencies Cause > --------------------------- > > Key: DROOLS-649 > URL: https://issues.jboss.org/browse/DROOLS-649 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Environment: Drools 6.1.0, WildFly 8.1, JDK 1.7 > Reporter: Patrick Thomas > Assignee: Michael Anstis > Labels: dependency, kie > Fix For: 6.2.0.CR3 > > > When I add a dependency to my project that has other dependencies, KIE fills up my log file with multiple warnings and errors. See the forum reference for a sampling of messages I am receiving. One single reference filled my log file with 8MB of messages. > KIE appears to attempt to load every dependency of my dependency, and every dependency of those dependencies, and so on. The system becomes unusable for a while. After the scan is done, my Type drop down in the Data Modeler is filled with so many classes that it is difficult to find what I need. > The last problem (not mentioned in the forum) is that I can't shut down WildFly. I seem to get stuck in an endless loop with the following message being displayed repeatedly: > 13:41:55,522 WARN [org.jbpm.executor.impl.ExecutorRunnable] (pool-14-thread-1) Error while executing jobs due to {}null > It's possible that WildFly would eventually shut down, but I end up stopping the task forcibly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 12:22:39 2014 From: issues at jboss.org (Stefan Guilhen (JIRA)) Date: Thu, 20 Nov 2014 12:22:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guilhen resolved SECURITY-868. ------------------------------------- Fix Version/s: PicketBox_4_9_0.Beta3 Resolution: Done > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_0.Beta3 > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 13:30:39 2014 From: issues at jboss.org (Patrick Thomas (JIRA)) Date: Thu, 20 Nov 2014 13:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-649) Complex Dependencies Cause In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021713#comment-13021713 ] Patrick Thomas commented on DROOLS-649: --------------------------------------- Thank you for your work. I will add a different JIRA. I wasn't sure if it was all the same problem or something separate. > Complex Dependencies Cause > --------------------------- > > Key: DROOLS-649 > URL: https://issues.jboss.org/browse/DROOLS-649 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Environment: Drools 6.1.0, WildFly 8.1, JDK 1.7 > Reporter: Patrick Thomas > Assignee: Michael Anstis > Labels: dependency, kie > Fix For: 6.2.0.CR3 > > > When I add a dependency to my project that has other dependencies, KIE fills up my log file with multiple warnings and errors. See the forum reference for a sampling of messages I am receiving. One single reference filled my log file with 8MB of messages. > KIE appears to attempt to load every dependency of my dependency, and every dependency of those dependencies, and so on. The system becomes unusable for a while. After the scan is done, my Type drop down in the Data Modeler is filled with so many classes that it is difficult to find what I need. > The last problem (not mentioned in the forum) is that I can't shut down WildFly. I seem to get stuck in an endless loop with the following message being displayed repeatedly: > 13:41:55,522 WARN [org.jbpm.executor.impl.ExecutorRunnable] (pool-14-thread-1) Error while executing jobs due to {}null > It's possible that WildFly would eventually shut down, but I end up stopping the task forcibly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 13:44:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 20 Nov 2014 13:44:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SASL-73) Release JBoss SASL 1.0.5.Final In-Reply-To: References: Message-ID: Darran Lofthouse created SASL-73: ------------------------------------ Summary: Release JBoss SASL 1.0.5.Final Key: SASL-73 URL: https://issues.jboss.org/browse/SASL-73 Project: SASL Provider Issue Type: Release Components: Build Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.5.CR2 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 13:48:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 20 Nov 2014 13:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SASL-73) Release JBoss SASL 1.0.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SASL-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved SASL-73. ---------------------------------- Resolution: Done > Release JBoss SASL 1.0.5.Final > ------------------------------ > > Key: SASL-73 > URL: https://issues.jboss.org/browse/SASL-73 > Project: SASL Provider > Issue Type: Release > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.5.CR2 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 13:49:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Thu, 20 Nov 2014 13:49:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-270) Upgrade to JBoss SASL 1.0.5.Final In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-270: --------------------------------------- Summary: Upgrade to JBoss SASL 1.0.5.Final Key: WFCORE-270 URL: https://issues.jboss.org/browse/WFCORE-270 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha14 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 13:52:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 13:52:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-270) Upgrade to JBoss SASL 1.0.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-270: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1164781 > Upgrade to JBoss SASL 1.0.5.Final > --------------------------------- > > Key: WFCORE-270 > URL: https://issues.jboss.org/browse/WFCORE-270 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 15:32:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Thu, 20 Nov 2014 15:32:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-179) Support nested expressions in management API and deployment descriptors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFCORE-179: --------------------------------------- Assignee: Brian Stansberry > Support nested expressions in management API and deployment descriptors > ----------------------------------------------------------------------- > > Key: WFCORE-179 > URL: https://issues.jboss.org/browse/WFCORE-179 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Users have requested support for expressions such as: > {code} > ${VAULT::oracle::${me}::0} > {code} > where "me" is a system property. > Allows externalization of the vault attribute name. > This will likely require JBMETA changes as well, as the deployment level stuff is there. > I want this to be a generic thing, not just a specific solution to the above example. So, something like, given a string, find the innermost expression, resolve it and then repeat until the input equals the output (i.e. there are no more expressions.) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 16:42:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 16:42:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-270) Upgrade to JBoss SASL 1.0.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021755#comment-13021755 ] RH Bugzilla Integration commented on WFCORE-270: ------------------------------------------------ Darran Lofthouse changed the Status of [bug 1164781|https://bugzilla.redhat.com/show_bug.cgi?id=1164781] from ASSIGNED to POST > Upgrade to JBoss SASL 1.0.5.Final > --------------------------------- > > Key: WFCORE-270 > URL: https://issues.jboss.org/browse/WFCORE-270 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 16:44:39 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Thu, 20 Nov 2014 16:44:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3256) IronJacamar 1.1.9.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene resolved WFLY-3256. -------------------------------- Resolution: Done > IronJacamar 1.1.9.Final > ----------------------- > > Key: WFLY-3256 > URL: https://issues.jboss.org/browse/WFLY-3256 > Project: WildFly > Issue Type: Component Upgrade > Components: JCA > Affects Versions: 8.1.0.Final > Reporter: Tomaz Cerar > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 16:48:39 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Thu, 20 Nov 2014 16:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3840) Update to HAL 2.4.0.Beta3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene resolved WFLY-3840. -------------------------------- Resolution: Done > Update to HAL 2.4.0.Beta3 > ------------------------- > > Key: WFLY-3840 > URL: https://issues.jboss.org/browse/WFLY-3840 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 16:48:39 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Thu, 20 Nov 2014 16:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3655) Update to web console 2.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene resolved WFLY-3655. -------------------------------- Resolution: Done > Update to web console 2.4.Final > ------------------------------- > > Key: WFLY-3655 > URL: https://issues.jboss.org/browse/WFLY-3655 > Project: WildFly > Issue Type: Feature Request > Components: Web Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 8.2.0.CR1 > > > Plenty of bugfixes and a log viewer implementation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 16:48:39 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 20 Nov 2014 16:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4027) RESTEasy ViolationReport is not processed by JAXB provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas resolved WFLY-4027. ---------------------------------- Resolution: Done > RESTEasy ViolationReport is not processed by JAXB provider > ---------------------------------------------------------- > > Key: WFLY-4027 > URL: https://issues.jboss.org/browse/WFLY-4027 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 8.1.0.Final, 8.2.0.CR1, 9.0.0.Alpha1 > Reporter: Harald Wellmann > Assignee: Stuart Douglas > Labels: resteasy, validation > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > When used in combination with Bean Validation, RESTEasy should wrap validation errors in a {{ValidationReport}} which should be included in the REST response, marshalled to JSON or XML, depending on the content type. > This does not work currently in WildFly 8.1.0.Final. > The issue was reported in RESTEASY-1054. and is marked as fixed in RESTEasy 3.0.9.Final. > However, I can still reproduce the issue with a local build of WildFly 8.2.0.CR1-SNAPSHOT (from the 8.x branch) which includes RESTEasy 3.0.10.Final. > Going back to WildFly 8.1.0.Final, the issue no longer occurs when I add > {code} > > {code} > to the {{module.xml}} descriptor of {{org.jboss.resteasy.resteasy-validator-provider-11}}. > The same fix works for 8.2.0.CR1-SNAPSHOT. > Looking at the module descriptor, it seems that 9.0.0.Alpha1 is also affected (but I did not test my sample on 9.0.0.Alpha1). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 16:50:39 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Thu, 20 Nov 2014 16:50:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2620) Zero Timeout Stateful EJB Leak (clustered) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene reassigned WFLY-2620: ---------------------------------- Assignee: Paul Ferraro (was: Eduardo Martins) > Zero Timeout Stateful EJB Leak (clustered) > ------------------------------------------ > > Key: WFLY-2620 > URL: https://issues.jboss.org/browse/WFLY-2620 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 8.2.0.CR1 > > > Stateful EJB instances are not removed from cache upon release, if the timeout is zero. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 16:55:39 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Thu, 20 Nov 2014 16:55:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4027) RESTEasy ViolationReport is not processed by JAXB provider In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021759#comment-13021759 ] Jason Greene commented on WFLY-4027: ------------------------------------ https://github.com/wildfly/wildfly/commit/890b6b377623c76779276852d25fd76df6a24425 > RESTEasy ViolationReport is not processed by JAXB provider > ---------------------------------------------------------- > > Key: WFLY-4027 > URL: https://issues.jboss.org/browse/WFLY-4027 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 8.1.0.Final, 8.2.0.CR1, 9.0.0.Alpha1 > Reporter: Harald Wellmann > Assignee: Stuart Douglas > Labels: resteasy, validation > Fix For: 8.2.0.CR1, 9.0.0.Beta1 > > > When used in combination with Bean Validation, RESTEasy should wrap validation errors in a {{ValidationReport}} which should be included in the REST response, marshalled to JSON or XML, depending on the content type. > This does not work currently in WildFly 8.1.0.Final. > The issue was reported in RESTEASY-1054. and is marked as fixed in RESTEasy 3.0.9.Final. > However, I can still reproduce the issue with a local build of WildFly 8.2.0.CR1-SNAPSHOT (from the 8.x branch) which includes RESTEasy 3.0.10.Final. > Going back to WildFly 8.1.0.Final, the issue no longer occurs when I add > {code} > > {code} > to the {{module.xml}} descriptor of {{org.jboss.resteasy.resteasy-validator-provider-11}}. > The same fix works for 8.2.0.CR1-SNAPSHOT. > Looking at the module descriptor, it seems that 9.0.0.Alpha1 is also affected (but I did not test my sample on 9.0.0.Alpha1). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 17:37:39 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Thu, 20 Nov 2014 17:37:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4067) DummyTransaction exception during session.invalidate with started conversation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Ferraro updated WFLY-4067: ------------------------------- Fix Version/s: 9.0.0.Beta1 > DummyTransaction exception during session.invalidate with started conversation > ------------------------------------------------------------------------------ > > Key: WFLY-4067 > URL: https://issues.jboss.org/browse/WFLY-4067 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Tom Schuller > Assignee: Paul Ferraro > Fix For: 9.0.0.Beta1 > > Attachments: convTest.war, convTest.zip > > > A DummyTransaction-IllegalStateException is thrown while invalidating a httpSession wit a started javax.enterprise.context.Converation. > We are working in "full-ha" with session distribution enabled ( in web.xml) > Under https://ci.jboss.org/hudson/job/WildFly-latest-master/1334/ everything is working fine. No exception is thrown > The exception is thrown starting with version https://ci.jboss.org/hudson/job/WildFly-latest-master/1340 to the latest now (#1475) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 17:39:39 2014 From: issues at jboss.org (Paul Ferraro (JIRA)) Date: Thu, 20 Nov 2014 17:39:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4105) Add support for explicit fork channel protocols In-Reply-To: References: Message-ID: Paul Ferraro created WFLY-4105: ---------------------------------- Summary: Add support for explicit fork channel protocols Key: WFLY-4105 URL: https://issues.jboss.org/browse/WFLY-4105 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 9.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 17:47:40 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Thu, 20 Nov 2014 17:47:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1470) Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021766#comment-13021766 ] Jason Greene commented on WFLY-1470: ------------------------------------ We are replacing jacorb, and do not wish to touch that code. The links above I have analyzed and believe them to be safe. > Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) > ------------------------------------------------------------------------------------------------- > > Key: WFLY-1470 > URL: https://issues.jboss.org/browse/WFLY-1470 > Project: WildFly > Issue Type: Task > Reporter: Carlo de Wolf > Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 17:47:40 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Thu, 20 Nov 2014 17:47:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1470) Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021766#comment-13021766 ] Jason Greene edited comment on WFLY-1470 at 11/20/14 5:47 PM: -------------------------------------------------------------- We are replacing jacorb, and do not wish to touch that code. The source files listed above I have analyzed and believe them to be safe. was (Author: jason.greene): We are replacing jacorb, and do not wish to touch that code. The links above I have analyzed and believe them to be safe. > Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) > ------------------------------------------------------------------------------------------------- > > Key: WFLY-1470 > URL: https://issues.jboss.org/browse/WFLY-1470 > Project: WildFly > Issue Type: Task > Reporter: Carlo de Wolf > Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 18:06:39 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Thu, 20 Nov 2014 18:06:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-237) CtClass#getAnnotation() etc does not refer to the class path of ClassPool In-Reply-To: References: Message-ID: Shigeru Chiba created JASSIST-237: ------------------------------------- Summary: CtClass#getAnnotation() etc does not refer to the class path of ClassPool Key: JASSIST-237 URL: https://issues.jboss.org/browse/JASSIST-237 Project: Javassist Issue Type: Bug Affects Versions: 3.18.2-GA Reporter: Shigeru Chiba Assignee: Shigeru Chiba Fix For: 3.19.0-GA The problem is that the current implementation only uses the ClassPool's classloader, and this class loader is not aware (in my case) of the types known by the ClassPool itself. Original post https://github.com/jboss-javassist/javassist/pull/18 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 18:23:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 18:23:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-187) cli deployment-overlay --redeploy-affected should check subdeployments as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021772#comment-13021772 ] RH Bugzilla Integration commented on WFCORE-187: ------------------------------------------------ Kabir Khan changed the Status of [bug 1151435|https://bugzilla.redhat.com/show_bug.cgi?id=1151435] from POST to MODIFIED > cli deployment-overlay --redeploy-affected should check subdeployments as well > ------------------------------------------------------------------------------ > > Key: WFCORE-187 > URL: https://issues.jboss.org/browse/WFCORE-187 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 1.0.0.Alpha11 > > > The redeploy-affected action of the deployment-overlay command checks only the top level deployments, although the changes sent by the command might have actually affected some subdeployments that won't be automatically redeployed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 18:23:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 18:23:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3999) cli deployment-overlay --redeploy-affected should check subdeployments as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021773#comment-13021773 ] RH Bugzilla Integration commented on WFLY-3999: ----------------------------------------------- Kabir Khan changed the Status of [bug 1151435|https://bugzilla.redhat.com/show_bug.cgi?id=1151435] from POST to MODIFIED > cli deployment-overlay --redeploy-affected should check subdeployments as well > ------------------------------------------------------------------------------ > > Key: WFLY-3999 > URL: https://issues.jboss.org/browse/WFLY-3999 > Project: WildFly > Issue Type: Enhancement > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 9.0.0.Beta1 > > > This issue has to be fixed in wildfly-core but the overlay tests are in the WildFly testsuite. This issue is for the tests covering this issue in WildFly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 18:25:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 18:25:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-269) CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021774#comment-13021774 ] RH Bugzilla Integration commented on WFCORE-269: ------------------------------------------------ Kabir Khan changed the Status of [bug 1149099|https://bugzilla.redhat.com/show_bug.cgi?id=1149099] from POST to MODIFIED > CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases > ------------------------------------------------------------------------------- > > Key: WFCORE-269 > URL: https://issues.jboss.org/browse/WFCORE-269 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > This is copy of https://bugzilla.redhat.com/show_bug.cgi?id=1149099 > Description: > The CLI freezes in phase of requesting username/password in some cases. > Reproducer > ========== > Run following command: > ./jboss-cli.sh -c << EOF > /core-service=management/security-realm=ManagementRealm/authentication=local:remove > reload > EOF -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 18:30:39 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Thu, 20 Nov 2014 18:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-237) CtClass#getAnnotation() etc does not refer to the class path of ClassPool In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shigeru Chiba closed JASSIST-237. --------------------------------- Resolution: Done > CtClass#getAnnotation() etc does not refer to the class path of ClassPool > ------------------------------------------------------------------------- > > Key: JASSIST-237 > URL: https://issues.jboss.org/browse/JASSIST-237 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.18.2-GA > Reporter: Shigeru Chiba > Assignee: Shigeru Chiba > Fix For: 3.19.0-GA > > > The problem is that the current implementation only uses the ClassPool's classloader, and this class loader is not aware (in my case) of the types known by the ClassPool itself. > Original post > https://github.com/jboss-javassist/javassist/pull/18 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 19:05:39 2014 From: issues at jboss.org (Marc Dzaebel (JIRA)) Date: Thu, 20 Nov 2014 19:05:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Bindings do not cache actual values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021779#comment-13021779 ] Marc Dzaebel commented on DROOLS-651: ------------------------------------- I agree with you analysis. The user could even cache himself or use the workaround above, so there is no urgent need for a new feature. There are certainly more important ideas than optional cache and (if I'm the first) the need seems to be seldom (so reject is ok). The workaround might be valuable in the documentation too. Thanks to the Davide, Mark and Mario Best regards, Marc > Bindings do not cache actual values > ----------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mario Fusco > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 19:09:39 2014 From: issues at jboss.org (Marc Dzaebel (JIRA)) Date: Thu, 20 Nov 2014 19:09:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Bindings do not cache actual values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021779#comment-13021779 ] Marc Dzaebel edited comment on DROOLS-651 at 11/20/14 7:09 PM: --------------------------------------------------------------- I agree with your analysis. The user could even cache himself or use the workaround above, so there is no urgent need for a new feature. There are certainly more important ideas than optional cache and (if I'm the first) the need seems to be seldom (so reject is ok). The workaround might be valuable in the documentation too. Thanks to the Davide, Mark and Mario Best regards, Marc was (Author: mdzaebel): I agree with you analysis. The user could even cache himself or use the workaround above, so there is no urgent need for a new feature. There are certainly more important ideas than optional cache and (if I'm the first) the need seems to be seldom (so reject is ok). The workaround might be valuable in the documentation too. Thanks to the Davide, Mark and Mario Best regards, Marc > Bindings do not cache actual values > ----------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mario Fusco > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 19:13:39 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Thu, 20 Nov 2014 19:13:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4106) jsp-file directive prevents RequestDispatcher#forward to work correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stuart Douglas moved UNDERTOW-346 to WFLY-4106: ----------------------------------------------- Project: WildFly (was: Undertow) Key: WFLY-4106 (was: UNDERTOW-346) Component/s: Web (Undertow) (was: Servlet) > jsp-file directive prevents RequestDispatcher#forward to work correctly > ----------------------------------------------------------------------- > > Key: WFLY-4106 > URL: https://issues.jboss.org/browse/WFLY-4106 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Environment: WildFly 8.1.0.Final on OSX running on JDK7 > Reporter: Peter Major > Assignee: Stuart Douglas > Attachments: example.war > > > When there is a servlet specified like: > {noformat} > > index > /index.jsp > > > index > /index > > {noformat} > and the backing JSP uses RequestDispatcher#forward pointing to a different JSP file, the JspServlet will unfortunately try to render the first JSP again, resulting in StackOverflowError in most of the time. > When investigating this issue with the debugger by making a sample request to /index, it appeared that JspFileHandler sets the request attribute Constants.JSP_FILE, and that will have the value of the JSP file from the directive. This is great, until the JSP itself tries to call RequestDispatcher#forward using a path on the servletcontext, such as /hello.jsp. In this scenario, JspFileHandler no longer gets invoked, because simply that JSP isn't bound to a servlet, so the request attribute remain the old value and JspServlet just simply grabs the value from the request attribute again and displays the /index.jsp again, and again, and again. > This looks to be a bug in Jastow, but I'm not really sure how to fix it. I would assume that using dispatcher#forward from a JSP to call an another JSP (even indirectly, i.e. through dispatching the request to a servlet, which then would dispatch the request to a JSP) should be within the bounds of the servlet spec, but let me know if I'm violating the spec with my application in any ways. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 19:24:39 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 20 Nov 2014 19:24:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4107) Upgrade HAL to 2.4.9.Final In-Reply-To: References: Message-ID: Harald Pehl created WFLY-4107: --------------------------------- Summary: Upgrade HAL to 2.4.9.Final Key: WFLY-4107 URL: https://issues.jboss.org/browse/WFLY-4107 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 8.2.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 19:24:39 2014 From: issues at jboss.org (Harald Pehl (JIRA)) Date: Thu, 20 Nov 2014 19:24:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4107) Upgrade HAL to 2.4.9.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harald Pehl updated WFLY-4107: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/6979) > Upgrade HAL to 2.4.9.Final > -------------------------- > > Key: WFLY-4107 > URL: https://issues.jboss.org/browse/WFLY-4107 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 8.2.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 20:00:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 20:00:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-210) IO error during deployment scanning triggers undeployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021781#comment-13021781 ] RH Bugzilla Integration commented on WFCORE-210: ------------------------------------------------ James Livingston changed the Status of [bug 1159709|https://bugzilla.redhat.com/show_bug.cgi?id=1159709] from ASSIGNED to POST > IO error during deployment scanning triggers undeployment > --------------------------------------------------------- > > Key: WFCORE-210 > URL: https://issues.jboss.org/browse/WFCORE-210 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: James Livingston > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > If an IO error such as reaching the file descriptor limit occurs during deployment scanning, the scanner continues with an empty deployment list causing it to undeploy applications. > This occurs because FileSystemDeploymentService.scanDirectory() treats File.listFiles() returning null as an empty list rather than an error. http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 notes that it returns an empty array if the directory is empty, and null if it is not a directory or an IO error occurs. > It should instead respond to a null return value by aborting the scanner run, with a log message, and not proceed to undeploy applications. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 20:18:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 20:18:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021783#comment-13021783 ] RH Bugzilla Integration commented on LOGMGR-99: ----------------------------------------------- James Perkins changed the Status of [bug 1071695|https://bugzilla.redhat.com/show_bug.cgi?id=1071695] from ASSIGNED to POST > Infinite recursion when exception stack frame class lookup fails > ---------------------------------------------------------------- > > Key: LOGMGR-99 > URL: https://issues.jboss.org/browse/LOGMGR-99 > Project: JBoss Log Manager > Issue Type: Bug > Affects Versions: 1.5.1.Final > Reporter: James Livingston > Assignee: James Perkins > Priority: Critical > Fix For: 1.3.3.Final, 1.4.4.Final, 1.5.4.Final, 2.0.0.Beta2 > > Attachments: logmgr99.war > > > To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader. > It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies. > If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example > {code} > ... > at org.jboss.logmanager.Logger.log(Logger.java:367) > at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109) > at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73) > at org.jboss.modules.Module.loadModuleClass(Module.java:527) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:266) > at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578) > at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421) > at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388) > at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150) > at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) > at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) > at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) > at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.Logger.logRaw(Logger.java:721) > at org.jboss.logmanager.Logger.logRaw(Logger.java:731) > at org.jboss.logmanager.Logger.log(Logger.java:367) > ... > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 21:28:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Thu, 20 Nov 2014 21:28:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021790#comment-13021790 ] shinzey shinzey commented on WFLY-4096: --------------------------------------- Setting "wildfly.jpa.twophasebootstrap" to "false" works. It's a valid workaround but also vender-specific. > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 21:30:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Thu, 20 Nov 2014 21:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021791#comment-13021791 ] shinzey shinzey commented on WFLY-4096: --------------------------------------- Just found that this issue had been reported before but still not resolved: https://issues.jboss.org/browse/WFLY-2727 > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 21:35:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Thu, 20 Nov 2014 21:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021792#comment-13021792 ] shinzey shinzey commented on WFLY-4096: --------------------------------------- However, with this workaround, CDI stops working. For example if I annotate a class with: {quote} @Named @Stateless @PermitAll @Path("rest") {quote} The the following exception is thrown when trying to access the service: {quote} org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBException: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance {quote} > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 21:41:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 21:41:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2806) Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-2806: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1166458 > Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem > ---------------------------------------------------------------------------------------- > > Key: WFLY-2806 > URL: https://issues.jboss.org/browse/WFLY-2806 > Project: WildFly > Issue Type: Feature Request > Components: Web Services > Reporter: Kyle Lape > Assignee: Alessio Soldano > Fix For: 9.0.0.Beta1 > > > If {{CXFServlet}} is defined in an app's {{web.xml}}, the webservices subsystem should always be disabled. (Of course the preference would be to stop using {{CXFServlet}} and follow the JAX-WS way to deploy web services.) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 20 21:49:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 20 Nov 2014 21:49:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2806) Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021793#comment-13021793 ] RH Bugzilla Integration commented on WFLY-2806: ----------------------------------------------- Kyle Lape changed the Status of [bug 1166458|https://bugzilla.redhat.com/show_bug.cgi?id=1166458] from NEW to POST > Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem > ---------------------------------------------------------------------------------------- > > Key: WFLY-2806 > URL: https://issues.jboss.org/browse/WFLY-2806 > Project: WildFly > Issue Type: Feature Request > Components: Web Services > Reporter: Kyle Lape > Assignee: Alessio Soldano > Fix For: 9.0.0.Beta1 > > > If {{CXFServlet}} is defined in an app's {{web.xml}}, the webservices subsystem should always be disabled. (Of course the preference would be to stop using {{CXFServlet}} and follow the JAX-WS way to deploy web services.) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:38:39 2014 From: issues at jboss.org (Ram S (JIRA)) Date: Fri, 21 Nov 2014 00:38:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBASMP-68) execute-commands does not work for module command In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBASMP-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021801#comment-13021801 ] Ram S commented on JBASMP-68: ----------------------------- Hi [~heatseeker], would you please share some details on the patching. thanks. > execute-commands does not work for module command > ------------------------------------------------- > > Key: JBASMP-68 > URL: https://issues.jboss.org/browse/JBASMP-68 > Project: JBoss AS Maven Plugins > Issue Type: Bug > Affects Versions: 7.6.Final > Reporter: Alfio Gloria > Assignee: James Perkins > > I'm trying to remove a jboss module by means of maven. > {code:xml} > > ${project.build.directory}/server/jboss72 > > > module remove --slot=main --name=system.layers.base.org.jboss.weld.core > > > > {code} > execute-commands fails with the following stack trace: > {code} > Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > 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:483) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > ... 19 more > Caused by: java.lang.IllegalArgumentException: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. > at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:180) > at org.jboss.as.plugin.cli.Commands.execute(Commands.java:134) > at org.jboss.as.plugin.cli.ExecuteCommands.execute(ExecuteCommands.java:71) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > ... 20 more > Caused by: org.jboss.as.cli.CommandLineException: JBOSS_HOME environment variable is not set. > at org.jboss.as.cli.handlers.module.ASModuleHandler.getModulesDir(ASModuleHandler.java:362) > at org.jboss.as.cli.handlers.module.ASModuleHandler.removeModule(ASModuleHandler.java:326) > at org.jboss.as.cli.handlers.module.ASModuleHandler.doHandle(ASModuleHandler.java:214) > at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86) > at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:581) > at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:176) > ... 23 more > {code} > (tested with the last snapshot too) > The problem comes from jboss-as-cli that needs the JBOSS_HOME to be set in order to add or remove modules. This is not a requirement for other commands such as deploy. > There are some points of confusion: > # JBOSS_HOME is set in .bashrc but IDEs do not read .bashrc, thereby it can work in some cases but not in others; > # usually there are more than one installation or jboss-as-maven-plugin can download the server; > # jbossHome config parameter is not take into account; > # what if I want to make operations on more the one server at the same time? > At the moment I solved by patching jboss-as-cli using a system property instead of environment variable. I don't know how to solve without touching jboss-as-cli. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:41 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4083) Upgrade Infinispan to 6.0.3.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-4083: ------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > Upgrade Infinispan to 6.0.3.Final > --------------------------------- > > Key: WFLY-4083 > URL: https://issues.jboss.org/browse/WFLY-4083 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:41 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3805) JGroupsBroadcastGroupConfiguration Serialization Problem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-3805: ------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > JGroupsBroadcastGroupConfiguration Serialization Problem > -------------------------------------------------------- > > Key: WFLY-3805 > URL: https://issues.jboss.org/browse/WFLY-3805 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Yong Hao Gao > Assignee: Yong Hao Gao > Fix For: 9.0.0.Beta1 > > > When configuring JMS connection factories using jgroups discovery group, the client will get serialization exceptions because we pass a JChannel which is not serializable. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:42 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called before all persistence units have performed database updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-3619: ------------------------------- Fix Version/s: (was: 8.2.0.Final) > XA END / un-enlist for database connection called before all persistence units have performed database updates > -------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3619 > URL: https://issues.jboss.org/browse/WFLY-3619 > Project: WildFly > Issue Type: Bug > Components: EJB, JCA, JPA / Hibernate, Transactions > Affects Versions: 8.0.0.Final > Environment: Windows 7 64-bit > JDK 1.8.0_05-b13 64-Bit > MS SQL Server 2012 database > Latest MS JDBC driver > XA datasource > Reporter: Andreas Liebscher > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 9.0.0.Beta1 > > Attachments: persistence.xml, server-9.0.0.Alpha1-SNAPHOT-trace.log, server-9.0.0.Alpha1-SNAPHOT.log, server-all-traces-full.log.gz, server-org-jboss-as-jpa.log, server.jca.log, server_MSSQL_Trace.log > > > While trying to port an EE application from JBoss5 to WF8 the following problem occurred: > EJBs (@Required) using JPA to do some data changes. > Some changes get already written to the database, others reside in the session cache. > After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion. > Then more changes are flushed to the database, but I run in a reproduceable database locking problem. > After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call. > There should be exactly one xa transaction active processing all data changes. > But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction. > After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour: > - a connection is enlisted and xa start called > - the same connection is used for several select / insert / update statements > - after return of the top EJB call on the same connection xa end and connection un-enlist is called > - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected. > Shouldn't xa end be called AFTER beforeCompletion / session flush!?! -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:42 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3602) Emit notifications for servers in domain mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-3602: ------------------------------- Fix Version/s: (was: 8.2.0.Final) > Emit notifications for servers in domain mode > --------------------------------------------- > > Key: WFLY-3602 > URL: https://issues.jboss.org/browse/WFLY-3602 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > emit notifications related to server lifecycle in domain mode: > * server-started > * server-stopped > * server-restarted > * server-destroyed > * server-killed > These notifications should be emitted from the corresponding server-config resource (under /host=XXX/server-config=YYY) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:42 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3110) Don't copy the contents to all hosts when assigning a deployment to a server-group In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-3110: ------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > Don't copy the contents to all hosts when assigning a deployment to a server-group > ---------------------------------------------------------------------------------- > > Key: WFLY-3110 > URL: https://issues.jboss.org/browse/WFLY-3110 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 9.0.0.Beta1 > > > When assigning a deployment to a server-group it also copies the actual deployment contents to all hosts regardless of the whether the deployment is used locally or not. This should be changed that the contents are only retrieved if they are actually needed on a local server. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:43 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2893) Determine cause of unreported test failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-2893: ------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > Determine cause of unreported test failures > ------------------------------------------- > > Key: WFLY-2893 > URL: https://issues.jboss.org/browse/WFLY-2893 > Project: WildFly > Issue Type: Task > Components: Build System, Test Suite > Affects Versions: 8.0.0.CR1 > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > Fix For: 9.0.0.Beta1 > > > Identify the reason why the failing tests that needed https://github.com/wildfly/wildfly/commit/90643bc435a9ba439cf2988e5b7407d1d48fb040 to get working did not fail the build. Those tests were failing for 2.5 months. Fortunately it was just a test problem, not a broken feature. > They involved separate surefire executions. We want to avoid those, but sometimes they are needed to use different config files. We have separate executions in testsuite/integration/basic as well, covering a much broader scope, so if this kind of problem happened there as well we could have a big problem. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:43 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2620) Zero Timeout Stateful EJB Leak (clustered) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-2620: ------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > Zero Timeout Stateful EJB Leak (clustered) > ------------------------------------------ > > Key: WFLY-2620 > URL: https://issues.jboss.org/browse/WFLY-2620 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.Beta1 > > > Stateful EJB instances are not removed from cache upon release, if the timeout is zero. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:43 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1895) Provide a "default" role for management users with no other role specified In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-1895: ------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > Provide a "default" role for management users with no other role specified > -------------------------------------------------------------------------- > > Key: WFLY-1895 > URL: https://issues.jboss.org/browse/WFLY-1895 > Project: WildFly > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Jakub Cechacek > Assignee: Emanuel Muckenhuber > Labels: rbac-filed-by-qa > Fix For: 9.0.0.Beta1 > > > Currently it seems that when using RBAC provider users with no defined role are unable to read domain model at all. Consequently logging into Admin Console leads to 500 error page. Similar errors in CLI. > In relation to this, it should be considered what is the expected behavior of unsecured management interface. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:43 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-465) Attribute check-for-live-server must set on live server to faillback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-465: ------------------------------ Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > Attribute check-for-live-server must set on live server to faillback > -------------------------------------------------------------------- > > Key: WFLY-465 > URL: https://issues.jboss.org/browse/WFLY-465 > Project: WildFly > Issue Type: Task > Components: JMS > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml > > > When there is live/backup pair with replicated journal then it should be sufficient to set attribute "check-for-live-server" in messaging subsystem only on backup to force backup server to shutdown when live server comes alive again. Problem is this won't happen. > Only when attribute "check-for-live-server" is set on live server then failback is successful (backup shutdown itself) > It's not well documented where "check-for-live-server" should be set in HornetQ project documentation: > http://docs.jboss.org/hornetq/2.3.0.CR1/docs/user-manual/html_single/index.html#ha.allow-fail-back > This issue was hit with EAP 6.1.0.DR2 (HQ 2.3.0.CR1). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:44 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-458) ServerInventory#reconnectServer should take auto-start into account In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-458: ------------------------------ Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFLY-458 > URL: https://issues.jboss.org/browse/WFLY-458 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Fix For: 9.0.0.Beta1 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:44 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-368) Naming subsystem could use LinkRef/Reference In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-368: ------------------------------ Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > Naming subsystem could use LinkRef/Reference > ----------------------------------------------------- > > Key: WFLY-368 > URL: https://issues.jboss.org/browse/WFLY-368 > Project: WildFly > Issue Type: Feature Request > Components: Naming > Reporter: James Livingston > Assignee: Eduardo Martins > Fix For: 9.0.0.Beta1 > > > NameBindingAdd.installLookup() sets up the machinery so that when Context.lookup() is done it looks up the redirected name and returns it. > It should be possible to do that by binding a LinkRef, Reference or similar object into JNDI instead. > Where this could make a difference is when Context.lookupLink() is called instead. > Currently if you have > > > lookupLink("java:/a") will return "hello" rather a LinkRef/Reference/whatever pointing to java:/b. > We need to decide whether a should be considered a "link" for the purposes of lookup() or not. If it should be considered one, then we should change NameBindingAdd.installLookup() to make lookupLink() return the other value. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:44 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-343) lower messaging's min-large-message-size value in standalone-full.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-343: ------------------------------ Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > lower messaging's min-large-message-size value in standalone-full.xml > --------------------------------------------------------------------- > > Key: WFLY-343 > URL: https://issues.jboss.org/browse/WFLY-343 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > AS7's messaging subsystem defines 2 attributes: > journal-file-size => 10MiB > min-large-message-size => 100KiB > However, for startup performance issue, the standalone-full.xml sets the journal-file-size at 1OOKiB. This leads to issues since it's the same value than the min-large-message-size. > If we want to keep a low journal-file-size value in standalone-full.xml, the min-large-message-size must also bet set appropriately (eg 75KiB?) > For production use, however, we should suggest to the users to remove the journal-file-size and min-large-message-size from standalone-full.xml to use the default values (resp. 10MiB & 100KiB) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:50:44 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Fri, 21 Nov 2014 00:50:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-261) Add way to properly parse JNDI urls in AS codebase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene updated WFLY-261: ------------------------------ Fix Version/s: 9.0.0.Beta1 (was: 8.2.0.Final) > Add way to properly parse JNDI urls in AS codebase > -------------------------------------------------- > > Key: WFLY-261 > URL: https://issues.jboss.org/browse/WFLY-261 > Project: WildFly > Issue Type: Feature Request > Components: Naming > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 9.0.0.Beta1 > > > This is a followup of AS7-2138. Original code, in case no URL context threw NamingException. The AS7-2138 introduced a fallback to NamingContext in case AS7 does not provide custom hack for url( like EJB ). However the fallback did not fail with NamingException in case it did not locate Context. This essentially made it go knee deep into AS7 service lookups, which hides real cause of failure. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 00:56:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 00:56:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-451) Filter Apache CXF In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-451: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1166502 > Filter Apache CXF > ----------------- > > Key: WFLY-451 > URL: https://issues.jboss.org/browse/WFLY-451 > Project: WildFly > Issue Type: Task > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 8.0.0.Alpha1 > > > Detect Apache CXF libraries in user deployment and *if* the webservices subsystem is actually being triggered for the deployment, either log a major warning or make the deployment fail. This would basically prevent later issues with users trying to deploy not properly packaged applications (e.g. the same war embedding CXF they were using on Tomcat) and making them aware of what they need to do. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 01:30:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 01:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-451) Filter Apache CXF In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021813#comment-13021813 ] RH Bugzilla Integration commented on WFLY-451: ---------------------------------------------- Kyle Lape changed the Status of [bug 1166502|https://bugzilla.redhat.com/show_bug.cgi?id=1166502] from NEW to POST > Filter Apache CXF > ----------------- > > Key: WFLY-451 > URL: https://issues.jboss.org/browse/WFLY-451 > Project: WildFly > Issue Type: Task > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 8.0.0.Alpha1 > > > Detect Apache CXF libraries in user deployment and *if* the webservices subsystem is actually being triggered for the deployment, either log a major warning or make the deployment fail. This would basically prevent later issues with users trying to deploy not properly packaged applications (e.g. the same war embedding CXF they were using on Tomcat) and making them aware of what they need to do. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 01:53:39 2014 From: issues at jboss.org (Miroslav Novak (JIRA)) Date: Fri, 21 Nov 2014 01:53:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-465) Attribute check-for-live-server must set on live server to faillback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Miroslav Novak closed WFLY-465. ------------------------------- Resolution: Done This is already resolved with EAP 6.3.0.ER7 - see bz#908261. Closing this jira. > Attribute check-for-live-server must set on live server to faillback > -------------------------------------------------------------------- > > Key: WFLY-465 > URL: https://issues.jboss.org/browse/WFLY-465 > Project: WildFly > Issue Type: Task > Components: JMS > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml > > > When there is live/backup pair with replicated journal then it should be sufficient to set attribute "check-for-live-server" in messaging subsystem only on backup to force backup server to shutdown when live server comes alive again. Problem is this won't happen. > Only when attribute "check-for-live-server" is set on live server then failback is successful (backup shutdown itself) > It's not well documented where "check-for-live-server" should be set in HornetQ project documentation: > http://docs.jboss.org/hornetq/2.3.0.CR1/docs/user-manual/html_single/index.html#ha.allow-fail-back > This issue was hit with EAP 6.1.0.DR2 (HQ 2.3.0.CR1). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 02:24:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 02:24:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on root-logger after add-handler operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021824#comment-13021824 ] RH Bugzilla Integration commented on WFLY-1712: ----------------------------------------------- Jay SenSharma changed the Status of [bug 1017881|https://bugzilla.redhat.com/show_bug.cgi?id=1017881] from CLOSED to ASSIGNED > Erroneous name attribute on root-logger after add-handler operation > -------------------------------------------------------------------- > > Key: WFLY-1712 > URL: https://issues.jboss.org/browse/WFLY-1712 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model. > {code} > "root-logger" => {"ROOT" => { > "filter" => undefined, > "filter-spec" => undefined, > "handlers" => [ > "FILE", > "CONSOLE" > ], > "level" => "INFO", > "name" => "CONSOLE" > }} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 02:33:39 2014 From: issues at jboss.org (Jay Kumar SenSharma (JIRA)) Date: Fri, 21 Nov 2014 02:33:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on root-logger after add-handler operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay Kumar SenSharma reopened WFLY-1712: --------------------------------------- > Erroneous name attribute on root-logger after add-handler operation > -------------------------------------------------------------------- > > Key: WFLY-1712 > URL: https://issues.jboss.org/browse/WFLY-1712 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model. > {code} > "root-logger" => {"ROOT" => { > "filter" => undefined, > "filter-spec" => undefined, > "handlers" => [ > "FILE", > "CONSOLE" > ], > "level" => "INFO", > "name" => "CONSOLE" > }} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 02:50:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 21 Nov 2014 02:50:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-211) HC is over eager to remove its content In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet updated WFCORE-211: ------------------------------------- Fix Version/s: 1.0.0.Alpha14 > HC is over eager to remove its content > -------------------------------------- > > Key: WFCORE-211 > URL: https://issues.jboss.org/browse/WFCORE-211 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha14 > > > If you deploy the same war twice (same hash with different names) on a domain then undeploy one the content is removed from the HC while it is still referenced and potentially useable. > The content is not removed from the servers content directory. > To reproduce : > deploy /home/ehsavoie/dev/wildfly/quickstart/ejb-in-war/target/wildfly-ejb-in-war.war --runtime-name=first.war --server-groups=main-server-group --name=first.war > deploy /home/ehsavoie/dev/wildfly/quickstart/ejb-in-war/target/wildfly-ejb-in-war.war --runtime-name=second.war --server-groups=main-server-group --name=second.war > undeploy first.war --all-relevant-server-groups -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 02:50:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 21 Nov 2014 02:50:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-222) Update domain configuration files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet updated WFCORE-222: ------------------------------------- Fix Version/s: 1.0.0.Alpha14 > Update domain configuration files > --------------------------------- > > Key: WFCORE-222 > URL: https://issues.jboss.org/browse/WFCORE-222 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha14 > > > After integration of WFCORE-75 the configuration files for the host haven't been updated to show this new option. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 02:51:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 21 Nov 2014 02:51:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet resolved WFCORE-213. -------------------------------------- Fix Version/s: (was: 1.0.0.Beta1) Resolution: Done > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 02:53:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 21 Nov 2014 02:53:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-178) ContentRepositoryImpl should not call File.deleteOnExit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet reopened WFCORE-178: -------------------------------------- > ContentRepositoryImpl should not call File.deleteOnExit > ------------------------------------------------------- > > Key: WFCORE-178 > URL: https://issues.jboss.org/browse/WFCORE-178 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > > ContentRepositoryImpl.removeContent calls File.deleteOnExit if it can't delete the content or parent dirs. This is very wrong: > 1) The grandparent dir may have other children completed unrelated to the item being removed. > 2) The content in question may have been restored before process exit. For example, a deployment is undeployed, and then a while later the same bits are uploaded again. > 3) File.deleteOnExit is a small memory leak. This one's relatively minor. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 02:54:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 21 Nov 2014 02:54:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-178) ContentRepositoryImpl should not call File.deleteOnExit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet updated WFCORE-178: ------------------------------------- Fix Version/s: 1.0.0.Alpha14 > ContentRepositoryImpl should not call File.deleteOnExit > ------------------------------------------------------- > > Key: WFCORE-178 > URL: https://issues.jboss.org/browse/WFCORE-178 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > ContentRepositoryImpl.removeContent calls File.deleteOnExit if it can't delete the content or parent dirs. This is very wrong: > 1) The grandparent dir may have other children completed unrelated to the item being removed. > 2) The content in question may have been restored before process exit. For example, a deployment is undeployed, and then a while later the same bits are uploaded again. > 3) File.deleteOnExit is a small memory leak. This one's relatively minor. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 02:54:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 21 Nov 2014 02:54:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-178) ContentRepositoryImpl should not call File.deleteOnExit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet resolved WFCORE-178. -------------------------------------- Resolution: Done > ContentRepositoryImpl should not call File.deleteOnExit > ------------------------------------------------------- > > Key: WFCORE-178 > URL: https://issues.jboss.org/browse/WFCORE-178 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > ContentRepositoryImpl.removeContent calls File.deleteOnExit if it can't delete the content or parent dirs. This is very wrong: > 1) The grandparent dir may have other children completed unrelated to the item being removed. > 2) The content in question may have been restored before process exit. For example, a deployment is undeployed, and then a while later the same bits are uploaded again. > 3) File.deleteOnExit is a small memory leak. This one's relatively minor. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 03:00:40 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 21 Nov 2014 03:00:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Bindings do not cache actual values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-651. -------------------------------- Resolution: Rejected > Bindings do not cache actual values > ----------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mario Fusco > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 03:19:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 03:19:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4079) Wildfly does not consider methods with no method-intf element when resolving transaction attributes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021835#comment-13021835 ] RH Bugzilla Integration commented on WFLY-4079: ----------------------------------------------- Jan Martiska changed the Status of [bug 1164060|https://bugzilla.redhat.com/show_bug.cgi?id=1164060] from ON_QA to VERIFIED > Wildfly does not consider methods with no method-intf element when resolving transaction attributes > --------------------------------------------------------------------------------------------------- > > Key: WFLY-4079 > URL: https://issues.jboss.org/browse/WFLY-4079 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > If there is a method without a method-intf the ejb-jar.xml it will not be considered when determining the transaction attribute. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 03:32:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 21 Nov 2014 03:32:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-271) The description of the default scanner attribute "scan-enabled" is incorrect. In-Reply-To: References: Message-ID: Emmanuel Hugonnet created WFCORE-271: ---------------------------------------- Summary: The description of the default scanner attribute "scan-enabled" is incorrect. Key: WFCORE-271 URL: https://issues.jboss.org/browse/WFCORE-271 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha13 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 03:33:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 21 Nov 2014 03:33:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-271) The description of the default scanner attribute "scan-enabled" is incorrect. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet updated WFCORE-271: ------------------------------------- Description: Description of problem: The description of the 'scan-enabled' attribute states "Flag indicating that all scanning (including initial scanning at startup) should be disabled." The default value of this attribute is "true", therefore I believe the description is incorrect. I propose that the description be changed to: "Flag indicating if all scanning (including initial scanning at startup) is enabled." > The description of the default scanner attribute "scan-enabled" is incorrect. > ------------------------------------------------------------------------------- > > Key: WFCORE-271 > URL: https://issues.jboss.org/browse/WFCORE-271 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > > Description of problem: The description of the 'scan-enabled' attribute states "Flag indicating that all scanning (including initial scanning at startup) should be disabled." The default value of this attribute is "true", therefore I believe the description is incorrect. > I propose that the description be changed to: "Flag indicating if all scanning (including initial scanning at startup) is enabled." -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 03:33:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 03:33:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-271) The description of the default scanner attribute "scan-enabled" is incorrect. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-271: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1162982 > The description of the default scanner attribute "scan-enabled" is incorrect. > ------------------------------------------------------------------------------- > > Key: WFCORE-271 > URL: https://issues.jboss.org/browse/WFCORE-271 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > > Description of problem: The description of the 'scan-enabled' attribute states "Flag indicating that all scanning (including initial scanning at startup) should be disabled." The default value of this attribute is "true", therefore I believe the description is incorrect. > I propose that the description be changed to: "Flag indicating if all scanning (including initial scanning at startup) is enabled." -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 03:42:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 21 Nov 2014 03:42:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021837#comment-13021837 ] Bela Ban commented on WFLY-1067: -------------------------------- Not sure if this is an option but since David mentioned TSL / SSL: the socket factory JGroups uses to create sockets when TCP is used as transport is pluggable, so it could be replaced with an SSL/TLS impl. > Integrate JGroups with core AS security infrastructure > ------------------------------------------------------ > > Key: WFLY-1067 > URL: https://issues.jboss.org/browse/WFLY-1067 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Security > Reporter: Brian Stansberry > Assignee: Richard Achmatowicz > > Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components. > Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 04:35:39 2014 From: issues at jboss.org (Marc Dzaebel (JIRA)) Date: Fri, 21 Nov 2014 04:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Bindings do not cache actual values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021779#comment-13021779 ] Marc Dzaebel edited comment on DROOLS-651 at 11/21/14 4:35 AM: --------------------------------------------------------------- I agree with your analysis. The user could even cache himself or use the workaround above, so there is no urgent need for a new feature. There are certainly more important ideas than optional cache and (if I'm the first) the need seems to be seldom (so reject is ok). The workaround might be valuable in the documentation too. Thanks to Davide, Mark and Mario Best regards, Marc was (Author: mdzaebel): I agree with your analysis. The user could even cache himself or use the workaround above, so there is no urgent need for a new feature. There are certainly more important ideas than optional cache and (if I'm the first) the need seems to be seldom (so reject is ok). The workaround might be valuable in the documentation too. Thanks to the Davide, Mark and Mario Best regards, Marc > Bindings do not cache actual values > ----------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mario Fusco > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 04:38:39 2014 From: issues at jboss.org (Marc Dzaebel (JIRA)) Date: Fri, 21 Nov 2014 04:38:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-651) Bindings do not cache actual values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020474#comment-13020474 ] Marc Dzaebel edited comment on DROOLS-651 at 11/21/14 4:37 AM: --------------------------------------------------------------- The documentation uses the term _binding variable_ 8 times, so bindings seems to be variables too (but of course special ones). I understand that these bindings are not yet cached because of constraint idempotence. However, in my view the implication should be, that especially a non changing result +can+ be cached! Rather than a _good practice_, the documentation says: {quote} "Property accessors +must+ not change the state of the object in a way that may effect the rules. Remember that the rule engine effectively +caches+ the results of its matching in between invocations to make it faster." {quote} So if kind of functional immutability is required and used inside the engine, I would indeed think about caching method calls (with variables) in constraints, as this saves potentially massive processor time and would be much more intuitive. I don't understand your sentence {quote} "If you can't or desire not to guarantee this property, Drools won't enforce it caching the first value returned." {quote} Is it possible, to enforce Drools to cache variable bindings? Drools shouldn't cache values, that change. Let me say that I'm still intrigued about the huge, powerful Drools framework and that we get this as Open Source including this helpful support. Feel free to change the issue-type to a feature request, as the behavior is not strictly incorrect but optimizable. was (Author: mdzaebel): The documentation uses the term _binding variable_ 8 times, so bindings seems to be a variables too (but of course special ones). I understand that these bindings are not yet cached because of constraint idempotence. However, in my view the implication should be, that especially a non changing result +can+ be cached! Rather than a _good practice_, the documentation says: {quote} "Property accessors +must+ not change the state of the object in a way that may effect the rules. Remember that the rule engine effectively +caches+ the results of its matching in between invocations to make it faster." {quote} So if kind of functional immutability is required and used inside the engine, I would indeed think about caching method calls (with variables) in constraints, as this saves potentially massive processor time and would be much more intuitive. I don't understand your sentence {quote} "If you can't or desire not to guarantee this property, Drools won't enforce it caching the first value returned." {quote} Is it possible, to enforce Drools to cache variable bindings? Drools shouldn't cache values, that change. Let me say that I'm still intrigued about the huge, powerful Drools framework and that we get this as Open Source including this helpful support. Feel free to change the issue-type to a feature request, as the behavior is not strictly incorrect but optimizable. > Bindings do not cache actual values > ----------------------------------- > > Key: DROOLS-651 > URL: https://issues.jboss.org/browse/DROOLS-651 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.Beta3 > Environment: Win7, Drools 6.2.0 Beta3 (probably all Drools versions) > Reporter: Marc Dzaebel > Assignee: Mario Fusco > Priority: Minor > > Create sample Drools project, add following method to the Message class: > {noformat} public List list() { > System.out.println("Call!"); > return Arrays.asList("one", "two"); > } {noformat} > sample.drl: > {noformat} > package com.sample > import com.sample.DroolsTest.Message; > import java.util.List; > import java.util.ArrayList; > > rule "" > when m : Message(L : list(), L.size>0) > then System.out.println("L:"+L); > end > {noformat} > Running the project will result in the following output: > {noformat} > Call! > Call! > L:[one, two] > {noformat} > So _list()_ is called *two* times (duplicate). This may be due to the replacement of "L" with _list()_ in the second constraint. This is ok for simple +getters+ as here HotSpot optimizes this away. However, long running methods will produce unnecessary overhead, especially if further constraints on "L" are added (which I verified produce additional calls to list()). So at least methods with one or more arguments should be saved in temporary variables that should be used in further constraints. A fix of this problem will certainly accelerate Drools performance on similar patterns. If this is not feasible, at least a comment should be added to the documentation. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 04:44:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 21 Nov 2014 04:44:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1903) TCPPING: discovery dissemination for static discovery protocols In-Reply-To: References: Message-ID: Bela Ban created JGRP-1903: ------------------------------ Summary: TCPPING: discovery dissemination for static discovery protocols Key: JGRP-1903 URL: https://issues.jboss.org/browse/JGRP-1903 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.1 For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically. Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches: |A|B|C|D|E| |ABCDE|AB|AC|AD|AE| Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D. h5. Solution * When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster * This can be done when a new member join, or periodically, or upon request (JMX) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 04:50:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 04:50:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-271) The description of the default scanner attribute "scan-enabled" is incorrect. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021851#comment-13021851 ] RH Bugzilla Integration commented on WFCORE-271: ------------------------------------------------ Emmanuel Hugonnet (ehsavoie) changed the Status of [bug 1162982|https://bugzilla.redhat.com/show_bug.cgi?id=1162982] from NEW to POST > The description of the default scanner attribute "scan-enabled" is incorrect. > ------------------------------------------------------------------------------- > > Key: WFCORE-271 > URL: https://issues.jboss.org/browse/WFCORE-271 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > > Description of problem: The description of the 'scan-enabled' attribute states "Flag indicating that all scanning (including initial scanning at startup) should be disabled." The default value of this attribute is "true", therefore I believe the description is incorrect. > I propose that the description be changed to: "Flag indicating if all scanning (including initial scanning at startup) is enabled." -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 04:59:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 04:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBWEB-248) The default error report class valve should be overridable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBWEB-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JBWEB-248: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1166584 > The default error report class valve should be overridable > ---------------------------------------------------------- > > Key: JBWEB-248 > URL: https://issues.jboss.org/browse/JBWEB-248 > Project: JBoss Web > Issue Type: Feature Request > Components: Tomcat > Affects Versions: JBossWeb-7.0.15.GA, JBossWeb-7.0.16.GA > Reporter: Vincent MATHON > Assignee: Remy Maucherat > > The default error report valve class cannot be configured since JBoss 7.x. > The current default implementation (org.apache.catalina.valves.ErrorReportValve) prints the stack trace if any or some server informations. This can be considered as a security issue, so, it would be great to be able to configure a custom error report valve class or at least to be able to filter informations printed by the default one. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 05:13:39 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Fri, 21 Nov 2014 05:13:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4108) Include all the cli tests into the default full profile in testsuite/integration/basic/pom.xml In-Reply-To: References: Message-ID: Alexey Loubyansky created WFLY-4108: --------------------------------------- Summary: Include all the cli tests into the default full profile in testsuite/integration/basic/pom.xml Key: WFLY-4108 URL: https://issues.jboss.org/browse/WFLY-4108 Project: WildFly Issue Type: Task Components: Test Suite Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: 9.0.0.Beta1 The CLI tests that are currently included in the default full profile are HelpTestCase and JmsTestCase, which doesn't make sense to me. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 05:33:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 21 Nov 2014 05:33:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1903) TCPPING: discovery dissemination for static discovery protocols In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-1903: --------------------------- Description: For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically. Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches: |A|B|C|D|E| |ABCDE|AB|AC|AD|AE| Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D. h5. Solution * When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster * This can be done when a new member join, or periodically, or upon request (JMX) * Should be goverened by a property: if someone lists all members in {{initial_hosts}}, then he may want to turn this off was: For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically. Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches: |A|B|C|D|E| |ABCDE|AB|AC|AD|AE| Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D. h5. Solution * When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster * This can be done when a new member join, or periodically, or upon request (JMX) > TCPPING: discovery dissemination for static discovery protocols > --------------------------------------------------------------- > > Key: JGRP-1903 > URL: https://issues.jboss.org/browse/JGRP-1903 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically. > Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches: > |A|B|C|D|E| > |ABCDE|AB|AC|AD|AE| > Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D. > h5. Solution > * When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster > * This can be done when a new member join, or periodically, or upon request (JMX) > * Should be goverened by a property: if someone lists all members in {{initial_hosts}}, then he may want to turn this off -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 05:41:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 05:41:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-851) Base64Utils class cuts leading zeroes from encoded bytes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021859#comment-13021859 ] RH Bugzilla Integration commented on SECURITY-851: -------------------------------------------------- Ondrej Kotek changed the Status of [bug 1125004|https://bugzilla.redhat.com/show_bug.cgi?id=1125004] from ON_QA to VERIFIED > Base64Utils class cuts leading zeroes from encoded bytes > -------------------------------------------------------- > > Key: SECURITY-851 > URL: https://issues.jboss.org/browse/SECURITY-851 > Project: PicketBox > Issue Type: Bug > Affects Versions: PicketBox_4_0_21.Beta2 > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Blocker > Fix For: PicketBox_4_0_21.Final > > > Vault util is failing for some password/salt/iteration combinations because Base64Utils class strips zeroes from provided byte array. > So if a user encodes a key with length 8 and the leading byte of the key is zero, then after decoding he only gets 7 (or less) bytes. > For instance: > {code} > encode ( { 0, 81, 121, -37, 46, -64, 20, 114 } ) -> "1HUTikm1Ho" > decode ("1HUTikm1Ho") -> { 81, 121, -37, 46, -64, 20, 114 } > {code} > As a result the PBEUtil will fail with javax.crypto.IllegalBlockSizeException. > IMHO the same problem can occur on other places where the Base64Utils class is used (not only the Vault). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 06:12:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 21 Nov 2014 06:12:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1903) TCPPING: discovery dissemination for static discovery protocols In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021867#comment-13021867 ] Bela Ban commented on JGRP-1903: -------------------------------- The _coordinator_ (only) does the following on a view change (if discovery dissemination is enabled and discovery protocol is static): * Determines the set of new members N and left members L * Sends information about everyone except self and L to N * Sends information about N to everyone except self and L There should also be a JMX exposed operation which sends information about everyone to everyone (except self) > TCPPING: discovery dissemination for static discovery protocols > --------------------------------------------------------------- > > Key: JGRP-1903 > URL: https://issues.jboss.org/browse/JGRP-1903 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically. > Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches: > |A|B|C|D|E| > |ABCDE|AB|AC|AD|AE| > Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D. > h5. Solution > * When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster > * This can be done when a new member join, or periodically, or upon request (JMX) > * Should be goverened by a property: if someone lists all members in {{initial_hosts}}, then he may want to turn this off -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 06:12:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 21 Nov 2014 06:12:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1903) TCPPING: discovery dissemination for static discovery protocols In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021868#comment-13021868 ] Bela Ban commented on JGRP-1903: -------------------------------- Since this is done mainly for the {{TCP:TCPPING}} combo, using {{TCP}} to send the information is reliable. > TCPPING: discovery dissemination for static discovery protocols > --------------------------------------------------------------- > > Key: JGRP-1903 > URL: https://issues.jboss.org/browse/JGRP-1903 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically. > Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches: > |A|B|C|D|E| > |ABCDE|AB|AC|AD|AE| > Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D. > h5. Solution > * When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster > * This can be done when a new member join, or periodically, or upon request (JMX) > * Should be goverened by a property: if someone lists all members in {{initial_hosts}}, then he may want to turn this off -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 06:44:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 06:44:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021883#comment-13021883 ] RH Bugzilla Integration commented on LOGMGR-99: ----------------------------------------------- Kabir Khan changed the Status of [bug 1071695|https://bugzilla.redhat.com/show_bug.cgi?id=1071695] from POST to MODIFIED > Infinite recursion when exception stack frame class lookup fails > ---------------------------------------------------------------- > > Key: LOGMGR-99 > URL: https://issues.jboss.org/browse/LOGMGR-99 > Project: JBoss Log Manager > Issue Type: Bug > Affects Versions: 1.5.1.Final > Reporter: James Livingston > Assignee: James Perkins > Priority: Critical > Fix For: 1.3.3.Final, 1.4.4.Final, 1.5.4.Final, 2.0.0.Beta2 > > Attachments: logmgr99.war > > > To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader. > It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies. > If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example > {code} > ... > at org.jboss.logmanager.Logger.log(Logger.java:367) > at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109) > at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73) > at org.jboss.modules.Module.loadModuleClass(Module.java:527) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:266) > at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578) > at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421) > at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388) > at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150) > at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) > at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) > at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) > at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.Logger.logRaw(Logger.java:721) > at org.jboss.logmanager.Logger.logRaw(Logger.java:731) > at org.jboss.logmanager.Logger.log(Logger.java:367) > ... > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 06:45:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 06:45:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-270) Upgrade to JBoss SASL 1.0.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021884#comment-13021884 ] RH Bugzilla Integration commented on WFCORE-270: ------------------------------------------------ Kabir Khan changed the Status of [bug 1164781|https://bugzilla.redhat.com/show_bug.cgi?id=1164781] from POST to MODIFIED > Upgrade to JBoss SASL 1.0.5.Final > --------------------------------- > > Key: WFCORE-270 > URL: https://issues.jboss.org/browse/WFCORE-270 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 06:48:39 2014 From: issues at jboss.org (Philippe Schaller (JIRA)) Date: Fri, 21 Nov 2014 06:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3417) Accessing the EJB 3 container configuration of the web console fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philippe Schaller closed WFLY-3417. ----------------------------------- Fix Version/s: 8.2.0.Final Resolution: Out of Date No longer an issue with 8.2.0.Final. > Accessing the EJB 3 container configuration of the web console fails > -------------------------------------------------------------------- > > Key: WFLY-3417 > URL: https://issues.jboss.org/browse/WFLY-3417 > Project: WildFly > Issue Type: Bug > Components: Web Console > Affects Versions: 8.1.0.CR2 > Environment: HAL 2.2.6.Final & 2.2.7.Final > WildFly 8.1.0.CR2 & 8.1.0.CR5 > JDK 1.7.0_55 > Win 7 > Reporter: Philippe Schaller > Assignee: Heiko Braun > Fix For: 8.2.0.Final > > > Accessing the EJB 3 container configuration of the web console returns this message: > Unknown error > Unexpected HTTP response: 500 > Request > { > "address" => [("subsystem" => "threads")], > "child-type" => "thread-factory", > "operation" => "read-children-resources", > "recursive" => true > } > Response > Internal Server Error > { > "outcome" => "failed", > "failure-description" => "JBAS014883: No resource definition is registered for address [(\"subsystem\" => \"threads\")]", > "rolled-back" => true > } -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 06:53:39 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Fri, 21 Nov 2014 06:53:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4109) Remove outdated policy files from testsuite/integration/src/test/config In-Reply-To: References: Message-ID: Josef Cacek created WFLY-4109: --------------------------------- Summary: Remove outdated policy files from testsuite/integration/src/test/config Key: WFLY-4109 URL: https://issues.jboss.org/browse/WFLY-4109 Project: WildFly Issue Type: Enhancement Components: Test Suite Reporter: Josef Cacek Assignee: Josef Cacek Priority: Minor Policy files no-op.policy and permit_all_testsuite.policy are outdated. They should be removed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 06:53:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 06:53:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4109) Remove outdated policy files from testsuite/integration/src/test/config In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4109: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1166130 > Remove outdated policy files from testsuite/integration/src/test/config > ----------------------------------------------------------------------- > > Key: WFLY-4109 > URL: https://issues.jboss.org/browse/WFLY-4109 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Minor > > Policy files no-op.policy and permit_all_testsuite.policy are outdated. They should be removed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 06:58:39 2014 From: issues at jboss.org (Anderson Parra de Paula (JIRA)) Date: Fri, 21 Nov 2014 06:58:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3953) @Schedule annotation produces "Cannot invoke timeout method because method null is not a timeout method" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021890#comment-13021890 ] Anderson Parra de Paula commented on WFLY-3953: ----------------------------------------------- I could not simulate this problem on development version: Please take a look at this code: @Singleton @Startup public class TimerTest { @Schedule(hour = "*", minute = "*", second="13") public void sayHello() { System.out.println("Hello"); } } Result: 11:53:13,005 INFO [stdout] (EJB default - 6) Hello 11:54:13,010 INFO [stdout] (EJB default - 7) Hello 11:55:13,007 INFO [stdout] (EJB default - 8) Hello 11:56:13,004 INFO [stdout] (EJB default - 9) Hello 11:57:13,040 INFO [stdout] (EJB default - 10) Hello > @Schedule annotation produces "Cannot invoke timeout method because method null is not a timeout method" > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-3953 > URL: https://issues.jboss.org/browse/WFLY-3953 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.1.0.Final > Reporter: Andrei Tchijov > Assignee: Stuart Douglas > > Please take a look at this gist : https://gist.github.com/leapingbytes/01838d9534638cb04200 > In case of @Schedule second and all consecutive invocations produce this > {code} > 13:19:30,635 ERROR U( ) [org.jboss.as.ejb3] (EJB default - 8) JBAS014120: Error invoking timeout for timer: [id=ba9f1c67-5a91-42ff-8276-f715efaa3723 timedObjectId=ChumbaServer-2.0-SNAPSHOT.ChumbaServer-2.0-SNAPSHOT.SettingsManagerImpl auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl at 5a898863 initialExpiration=Wed Oct 08 13:17:30 EEST 2014 intervalDuration(in milli sec)=60000 nextExpiration=Wed Oct 08 13:20:30 EEST 2014 timerState=IN_TIMEOUT info=null: java.lang.RuntimeException: JBAS014481: Cannot invoke timeout method because method null is not a timeout method > at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:84) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:114) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.ejb3.timerservice.task.TimerTask.callTimeout(TimerTask.java:196) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.ejb3.timerservice.task.TimerTask.run(TimerTask.java:168) [wildfly-ejb3-8.1.0.Final.jar:8.1.0.Final] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_67] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_67] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_67] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_67] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_67] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 07:06:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 07:06:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4109) Remove outdated policy files from testsuite/integration/src/test/config In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021894#comment-13021894 ] RH Bugzilla Integration commented on WFLY-4109: ----------------------------------------------- Josef Cacek changed the Status of [bug 1166130|https://bugzilla.redhat.com/show_bug.cgi?id=1166130] from NEW to POST > Remove outdated policy files from testsuite/integration/src/test/config > ----------------------------------------------------------------------- > > Key: WFLY-4109 > URL: https://issues.jboss.org/browse/WFLY-4109 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Minor > > Policy files no-op.policy and permit_all_testsuite.policy are outdated. They should be removed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 07:35:40 2014 From: issues at jboss.org (Max Weidemann (JIRA)) Date: Fri, 21 Nov 2014 07:35:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3149) Windows service on 64 bit systems cannot be stopped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021907#comment-13021907 ] Max Weidemann commented on WFLY-3149: ------------------------------------- Hi i had the same Problem and could fixt it by installing the service with the controller param with the value 127.0.0.1:10090. (complete command: service.bat install /user Admin /password **** /controller 127.0.0.1:10090) i had to do so because i added the following value to my JAVA_OPTS in the standalone.conf.bat file. set "JAVA_OPTS=%JAVA_OPTS% -Djboss.socket.binding.port-offset=100" I used Wildfly 8.1.0 with Java 7. > Windows service on 64 bit systems cannot be stopped > --------------------------------------------------- > > Key: WFLY-3149 > URL: https://issues.jboss.org/browse/WFLY-3149 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.0.0.Final > Environment: Windows 2008 Server, Windows 7 professional - both 64 bit systems using JDK 1.7.0_09 > Reporter: Mohan Potturi > Assignee: Mladen Turk > > The Windows service cannot be stopped. It says 'stopping' in the windows service user interface window. The only way to stop it is ti actually kill the java process. It works flawlessly on 32 bit systems though. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 07:36:40 2014 From: issues at jboss.org (Max Weidemann (JIRA)) Date: Fri, 21 Nov 2014 07:36:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3149) Windows service on 64 bit systems cannot be stopped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021907#comment-13021907 ] Max Weidemann edited comment on WFLY-3149 at 11/21/14 7:36 AM: --------------------------------------------------------------- Hi i had the same Problem and could fixt it by installing the service with the controller param with the value 127.0.0.1:10090. (complete command: service.bat install /user Admin /password **** /controller 127.0.0.1:10090) i had to do so because i added the following value to my JAVA_OPTS in the standalone.conf.bat file. set "JAVA_OPTS=%JAVA_OPTS% -Djboss.socket.binding.port-offset=100" I used Wildfly 8.1.0 with Java 7 on Windows Server 2012 64 bit. was (Author: max.weidemann): Hi i had the same Problem and could fixt it by installing the service with the controller param with the value 127.0.0.1:10090. (complete command: service.bat install /user Admin /password **** /controller 127.0.0.1:10090) i had to do so because i added the following value to my JAVA_OPTS in the standalone.conf.bat file. set "JAVA_OPTS=%JAVA_OPTS% -Djboss.socket.binding.port-offset=100" I used Wildfly 8.1.0 with Java 7. > Windows service on 64 bit systems cannot be stopped > --------------------------------------------------- > > Key: WFLY-3149 > URL: https://issues.jboss.org/browse/WFLY-3149 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.0.0.Final > Environment: Windows 2008 Server, Windows 7 professional - both 64 bit systems using JDK 1.7.0_09 > Reporter: Mohan Potturi > Assignee: Mladen Turk > > The Windows service cannot be stopped. It says 'stopping' in the windows service user interface window. The only way to stop it is ti actually kill the java process. It works flawlessly on 32 bit systems though. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 07:52:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Fri, 21 Nov 2014 07:52:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1903) TCPPING: discovery dissemination for static discovery protocols In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban resolved JGRP-1903. ---------------------------- Resolution: Done > TCPPING: discovery dissemination for static discovery protocols > --------------------------------------------------------------- > > Key: JGRP-1903 > URL: https://issues.jboss.org/browse/JGRP-1903 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically. > Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches: > |A|B|C|D|E| > |ABCDE|AB|AC|AD|AE| > Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D. > h5. Solution > * When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster > * This can be done when a new member join, or periodically, or upon request (JMX) > * Should be goverened by a property: if someone lists all members in {{initial_hosts}}, then he may want to turn this off -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 08:18:39 2014 From: issues at jboss.org (Dominik Pospisil (JIRA)) Date: Fri, 21 Nov 2014 08:18:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4110) EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used In-Reply-To: References: Message-ID: Dominik Pospisil created WFLY-4110: -------------------------------------- Summary: EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used Key: WFLY-4110 URL: https://issues.jboss.org/browse/WFLY-4110 Project: WildFly Issue Type: Bug Components: Clustering, Test Suite Affects Versions: 9.0.0.Alpha1 Reporter: Dominik Pospisil Assignee: Dominik Pospisil -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 08:21:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 08:21:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4110) EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4110: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1164231 > EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used > --------------------------------------------------------------------------------------- > > Key: WFLY-4110 > URL: https://issues.jboss.org/browse/WFLY-4110 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: Dominik Pospisil > Assignee: Dominik Pospisil > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 08:33:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 08:33:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4110) EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021928#comment-13021928 ] RH Bugzilla Integration commented on WFLY-4110: ----------------------------------------------- Dominik Pospisil changed the Status of [bug 1164231|https://bugzilla.redhat.com/show_bug.cgi?id=1164231] from ASSIGNED to POST > EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used > --------------------------------------------------------------------------------------- > > Key: WFLY-4110 > URL: https://issues.jboss.org/browse/WFLY-4110 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: Dominik Pospisil > Assignee: Dominik Pospisil > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 08:36:40 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Fri, 21 Nov 2014 08:36:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4111) Unable to read web-application files using ServletContext.getResourceAsStream when security manager is used In-Reply-To: References: Message-ID: Josef Cacek created WFLY-4111: --------------------------------- Summary: Unable to read web-application files using ServletContext.getResourceAsStream when security manager is used Key: WFLY-4111 URL: https://issues.jboss.org/browse/WFLY-4111 Project: WildFly Issue Type: Bug Components: Security Manager Reporter: Josef Cacek Assignee: Stefan Guilhen Servlets should be able to read application files by using ServletContext.getResourceAsStream without specifying additional permissions. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 08:47:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 21 Nov 2014 08:47:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4111) Unable to read web-application files using ServletContext.getResourceAsStream when security manager is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021932#comment-13021932 ] David Lloyd commented on WFLY-4111: ----------------------------------- I think that (at least for JARs) we have automatically added read permission for the deployment to read its own content directory. Maybe that part is failing for servlets somehow. > Unable to read web-application files using ServletContext.getResourceAsStream when security manager is used > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-4111 > URL: https://issues.jboss.org/browse/WFLY-4111 > Project: WildFly > Issue Type: Bug > Components: Security Manager > Reporter: Josef Cacek > Assignee: Stefan Guilhen > > Servlets should be able to read application files by using ServletContext.getResourceAsStream without specifying additional permissions. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 08:48:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 21 Nov 2014 08:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4111) Unable to read web-application files using ServletContext.getResourceAsStream when security manager is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFLY-4111: ------------------------------ Component/s: Web (Undertow) (was: Security Manager) > Unable to read web-application files using ServletContext.getResourceAsStream when security manager is used > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-4111 > URL: https://issues.jboss.org/browse/WFLY-4111 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Josef Cacek > Assignee: Stefan Guilhen > > Servlets should be able to read application files by using ServletContext.getResourceAsStream without specifying additional permissions. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 08:48:40 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 21 Nov 2014 08:48:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4111) Unable to read web-application files using ServletContext.getResourceAsStream when security manager is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFLY-4111: ------------------------------ Assignee: Stuart Douglas (was: Stefan Guilhen) > Unable to read web-application files using ServletContext.getResourceAsStream when security manager is used > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-4111 > URL: https://issues.jboss.org/browse/WFLY-4111 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > > Servlets should be able to read application files by using ServletContext.getResourceAsStream without specifying additional permissions. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 09:31:40 2014 From: issues at jboss.org (Anderson Parra de Paula (JIRA)) Date: Fri, 21 Nov 2014 09:31:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3935) cluster-ha-singleton fails to deploy when the server is started with the debug flag In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021949#comment-13021949 ] Anderson Parra de Paula commented on WFLY-3935: ----------------------------------------------- I didn't have problems to run this application on current development version using debug mode. Please, take a look at log: 14:27:54,664 INFO [org.jboss.as.server] (XNIO-1 task-7) WFLYSRV0010: Deployed "wildfly-cluster-ha-singleton-service.jar" (runtime-name : "wildfly-cluster-ha-singleton-service.jar") 14:28:00,010 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 1) HASingletonTimer: Info=HASingleton timer @jb.node1 Fri Nov 21 14:27:54 GMT 2014 14:28:10,002 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 2) HASingletonTimer: Info=HASingleton timer @jb.node1 Fri Nov 21 14:27:54 GMT 2014 14:28:20,002 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 3) HASingletonTimer: Info=HASingleton timer @jb.node1 Fri Nov 21 14:27:54 GMT 2014 14:28:30,001 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 4) HASingletonTimer: Info=HASingleton timer @jb.node1 Fri Nov 21 14:27:54 GMT 2014 14:28:40,024 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 5) HASingletonTimer: Info=HASingleton timer @jb.node1 Fri Nov 21 14:27:54 GMT 2014 14:28:50,015 INFO [org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.SchedulerBean] (EJB default - 6) HASingletonTimer: Info=HASingleton timer @jb.node1 Fri Nov 21 14:27:54 GMT 2014 > cluster-ha-singleton fails to deploy when the server is started with the debug flag > ----------------------------------------------------------------------------------- > > Key: WFLY-3935 > URL: https://issues.jboss.org/browse/WFLY-3935 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Euan Mapham > Assignee: Jason Greene > > When a clustered-ha-singleton is deployed to a wildfly server that was started using the --debug option, a org.jboss.msc.service.ServiceNotFoundException occurrs. > I am using the quickstart/cluster-ha-singleton found on github: > https://github.com/wildfly/quickstart/tree/master/cluster-ha-singleton > Wildfly version 8.1.0.Final > I start the server with this command: > ./bin/standalone.sh --debug -server-config=standalone-ha.xml -Djboss.node.name=jb.node1 > I then deploy the wildfly-cluster-ha-singleton-service.jar. > The exception that occurrs is: > 15:03:31,803 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."wildfly-cluster-ha-singleton-service.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-cluster-ha-singleton-service.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "wildfly-cluster-ha-singleton-service.jar" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.clustering.singleton.builder.server.default not found > at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:72) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 5 more > Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.clustering.singleton.builder.server.default not found > at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:668) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.DelegatingServiceRegistry.getRequiredService(DelegatingServiceRegistry.java:46) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator.install(HATimerServiceActivator.java:51) > at org.jboss.as.quickstarts.cluster.hasingleton.service.ejb.HATimerServiceActivator.activate(HATimerServiceActivator.java:44) > at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:70) [wildfly-server-8.1.0.Final.jar:8.1.0.Final] > ... 6 more > When I remove the "--debug" option from the command to start the server, everything works fine. > This means we cannot debug our applications if we use this feature. > Regards, > Euan -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 09:48:39 2014 From: issues at jboss.org (Anderson Parra de Paula (JIRA)) Date: Fri, 21 Nov 2014 09:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3931) Custom formatter property changes not written to, but overriden by logging.properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021955#comment-13021955 ] Anderson Parra de Paula commented on WFLY-3931: ----------------------------------------------- Hello Vsevolod Golovanov. Please, could you attach your standalone.xml for that I will simulate this problem. Thank you! > Custom formatter property changes not written to, but overriden by logging.properties > ------------------------------------------------------------------------------------- > > Key: WFLY-3931 > URL: https://issues.jboss.org/browse/WFLY-3931 > Project: WildFly > Issue Type: Bug > Components: Logging > Affects Versions: 8.1.0.Final > Environment: Wildfly 8.1.0.Final > Reporter: Vsevolod Golovanov > Assignee: James Perkins > > When you first add custom formatter with properties to standalone.xml, on server start property values get correctly resolved and written to logging.properties. > If you change property values in standalone.xml of an existing custom formatter, that was flushed to logging.properties before, then on the next server start new values don't get written to logging.properties and formatter instance gets the old values from logging.properties. > For properties with static values that are defined in standalone.xml there is a workaround: change the custom formatter name each time you change a property value. > But with more dynamic properties, e.g. that rely on system properties, it's not so simple... -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:16:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 10:16:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2806) Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021966#comment-13021966 ] RH Bugzilla Integration commented on WFLY-2806: ----------------------------------------------- Kabir Khan changed the Status of [bug 1166458|https://bugzilla.redhat.com/show_bug.cgi?id=1166458] from POST to MODIFIED > Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem > ---------------------------------------------------------------------------------------- > > Key: WFLY-2806 > URL: https://issues.jboss.org/browse/WFLY-2806 > Project: WildFly > Issue Type: Feature Request > Components: Web Services > Reporter: Kyle Lape > Assignee: Alessio Soldano > Fix For: 9.0.0.Beta1 > > > If {{CXFServlet}} is defined in an app's {{web.xml}}, the webservices subsystem should always be disabled. (Of course the preference would be to stop using {{CXFServlet}} and follow the JAX-WS way to deploy web services.) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:17:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 10:17:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-271) The description of the default scanner attribute "scan-enabled" is incorrect. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021967#comment-13021967 ] RH Bugzilla Integration commented on WFCORE-271: ------------------------------------------------ Kabir Khan changed the Status of [bug 1162982|https://bugzilla.redhat.com/show_bug.cgi?id=1162982] from POST to MODIFIED > The description of the default scanner attribute "scan-enabled" is incorrect. > ------------------------------------------------------------------------------- > > Key: WFCORE-271 > URL: https://issues.jboss.org/browse/WFCORE-271 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > > Description of problem: The description of the 'scan-enabled' attribute states "Flag indicating that all scanning (including initial scanning at startup) should be disabled." The default value of this attribute is "true", therefore I believe the description is incorrect. > I propose that the description be changed to: "Flag indicating if all scanning (including initial scanning at startup) is enabled." -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:20:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 21 Nov 2014 10:20:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-650) Sequential Phreak is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-650: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Sequential Phreak is broken > ---------------------------- > > Key: DROOLS-650 > URL: https://issues.jboss.org/browse/DROOLS-650 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.0.1.Final, 6.1.0.Final, 6.2.0.CR2 > Reporter: Mark Proctor > Assignee: Mario Fusco > Fix For: 6.2.0.CR3 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:20:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 10:20:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-451) Filter Apache CXF In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021970#comment-13021970 ] RH Bugzilla Integration commented on WFLY-451: ---------------------------------------------- Kabir Khan changed the Status of [bug 1166502|https://bugzilla.redhat.com/show_bug.cgi?id=1166502] from POST to MODIFIED > Filter Apache CXF > ----------------- > > Key: WFLY-451 > URL: https://issues.jboss.org/browse/WFLY-451 > Project: WildFly > Issue Type: Task > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 8.0.0.Alpha1 > > > Detect Apache CXF libraries in user deployment and *if* the webservices subsystem is actually being triggered for the deployment, either log a major warning or make the deployment fail. This would basically prevent later issues with users trying to deploy not properly packaged applications (e.g. the same war embedding CXF they were using on Tomcat) and making them aware of what they need to do. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:21:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Fri, 21 Nov 2014 10:21:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-650) Sequential Phreak is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco resolved DROOLS-650. -------------------------------- Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/4aeaa9fc179ac8ccf0b2b80520493b96b608e140 > Sequential Phreak is broken > ---------------------------- > > Key: DROOLS-650 > URL: https://issues.jboss.org/browse/DROOLS-650 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.0.1.Final, 6.1.0.Final, 6.2.0.CR2 > Reporter: Mark Proctor > Assignee: Mario Fusco > Fix For: 6.2.0.CR3 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:21:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 10:21:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-210) IO error during deployment scanning triggers undeployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021972#comment-13021972 ] RH Bugzilla Integration commented on WFCORE-210: ------------------------------------------------ Kabir Khan changed the Status of [bug 1159709|https://bugzilla.redhat.com/show_bug.cgi?id=1159709] from POST to MODIFIED > IO error during deployment scanning triggers undeployment > --------------------------------------------------------- > > Key: WFCORE-210 > URL: https://issues.jboss.org/browse/WFCORE-210 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: James Livingston > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > If an IO error such as reaching the file descriptor limit occurs during deployment scanning, the scanner continues with an empty deployment list causing it to undeploy applications. > This occurs because FileSystemDeploymentService.scanDirectory() treats File.listFiles() returning null as an empty list rather than an error. http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 notes that it returns an empty array if the directory is empty, and null if it is not a directory or an IO error occurs. > It should instead respond to a null return value by aborting the scanner run, with a log message, and not proceed to undeploy applications. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:22:39 2014 From: issues at jboss.org (Cody Lerum (JIRA)) Date: Fri, 21 Nov 2014 10:22:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4112) Update Wildfly JDF Stacks (BOM) for 8.2.0.Final In-Reply-To: References: Message-ID: Cody Lerum created WFLY-4112: -------------------------------- Summary: Update Wildfly JDF Stacks (BOM) for 8.2.0.Final Key: WFLY-4112 URL: https://issues.jboss.org/browse/WFLY-4112 Project: WildFly Issue Type: Feature Request Affects Versions: 8.1.0.Final Reporter: Cody Lerum Assignee: Tomaz Cerar Fix For: 8.1.0.Final The JDF stacks haven't been updated for Wildfly 8.1.0.Final This creates an issue for users wishing to keep the provided impl versions in sync with their project for debugging purposes. For example org.wildfly.bom:jboss-javaee-7.0-with-hibernate:8.0.0.Final specifes hibernate-search version 4.5.0.Final while Wildfly 8.1.0.Final bundles 4.5.1.Final -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:22:39 2014 From: issues at jboss.org (Cody Lerum (JIRA)) Date: Fri, 21 Nov 2014 10:22:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4112) Update Wildfly JDF Stacks (BOM) for 8.2.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cody Lerum updated WFLY-4112: ----------------------------- Fix Version/s: (was: 8.1.0.Final) Affects Version/s: 8.2.0.Final (was: 8.1.0.Final) Description: The JDF stacks haven't been updated for Wildfly 8.2.0.Final This creates an issue for users wishing to keep the provided impl versions in sync with their project for debugging purposes. was: The JDF stacks haven't been updated for Wildfly 8.1.0.Final This creates an issue for users wishing to keep the provided impl versions in sync with their project for debugging purposes. For example org.wildfly.bom:jboss-javaee-7.0-with-hibernate:8.0.0.Final specifes hibernate-search version 4.5.0.Final while Wildfly 8.1.0.Final bundles 4.5.1.Final > Update Wildfly JDF Stacks (BOM) for 8.2.0.Final > ----------------------------------------------- > > Key: WFLY-4112 > URL: https://issues.jboss.org/browse/WFLY-4112 > Project: WildFly > Issue Type: Feature Request > Affects Versions: 8.2.0.Final > Reporter: Cody Lerum > Assignee: Tomaz Cerar > > The JDF stacks haven't been updated for Wildfly 8.2.0.Final > This creates an issue for users wishing to keep the provided impl versions in sync with their project for debugging purposes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:26:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 21 Nov 2014 10:26:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-272) Provide a "default" role for management users with no other role specified In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved WFLY-1895 to WFCORE-272: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-272 (was: WFLY-1895) Component/s: Domain Management Security (was: Domain Management) (was: Security) Fix Version/s: 1.0.0.CR1 (was: 9.0.0.Beta1) > Provide a "default" role for management users with no other role specified > -------------------------------------------------------------------------- > > Key: WFCORE-272 > URL: https://issues.jboss.org/browse/WFCORE-272 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Jakub Cechacek > Assignee: Emanuel Muckenhuber > Labels: rbac-filed-by-qa > Fix For: 1.0.0.CR1 > > > Currently it seems that when using RBAC provider users with no defined role are unable to read domain model at all. Consequently logging into Admin Console leads to 500 error page. Similar errors in CLI. > In relation to this, it should be considered what is the expected behavior of unsecured management interface. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:27:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Fri, 21 Nov 2014 10:27:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-273) ServerInventory#reconnectServer should take auto-start into account In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved WFLY-458 to WFCORE-273: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-273 (was: WFLY-458) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.CR1 (was: 9.0.0.Beta1) > ServerInventory#reconnectServer should take auto-start into account > ------------------------------------------------------------------- > > Key: WFCORE-273 > URL: https://issues.jboss.org/browse/WFCORE-273 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Emanuel Muckenhuber > Fix For: 1.0.0.CR1 > > > When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:28:39 2014 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Fri, 21 Nov 2014 10:28:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021975#comment-13021975 ] Scott Marlow commented on WFLY-4096: ------------------------------------ I know about the CDI issue. There are other issues as well. The persistence unit has to be started, very early in deployment (before any application classes are loaded so that entity class rewriting works), but the CDI beanmanager will not be ready until very late. Same is true for datasources created in the deployment (@DataSourceDefinition). Can we start the CDI beanmanager earlier? I was told no, as the application classloader is expected to be used. Can we start application defined datasources early? I was told no on that as well. This all came up on the as7 or wildfly development email list before. Regarding the hibernate.temp.use_jdbc_metadata_defaults property, did you get any further in Hibernate with that (if you looked at the deployment exception call stack?) > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:35:42 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 21 Nov 2014 10:35:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-869) Session created if it doesn't exist even if authentication does not occur. In-Reply-To: References: Message-ID: Darran Lofthouse created SECURITY-869: ----------------------------------------- Summary: Session created if it doesn't exist even if authentication does not occur. Key: SECURITY-869 URL: https://issues.jboss.org/browse/SECURITY-869 Project: PicketBox Issue Type: Bug Components: Negotiation Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_2_3_5.Final -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:58:39 2014 From: issues at jboss.org (Peter Major (JIRA)) Date: Fri, 21 Nov 2014 10:58:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4113) 8.2.0.Final build hangs In-Reply-To: References: Message-ID: Peter Major created WFLY-4113: --------------------------------- Summary: 8.2.0.Final build hangs Key: WFLY-4113 URL: https://issues.jboss.org/browse/WFLY-4113 Project: WildFly Issue Type: Feature Request Components: Test Suite Affects Versions: 8.2.0.Final Reporter: Peter Major When trying to build 8.2.0.Final locally, my build just hangs indefinitely while executing a unit test in the controller module: {noformat} Running org.jboss.as.controller.ModelControllerClientTestCase {noformat} Running jstack against the build suggests that there is a deadlock between {noformat} - waiting to lock <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560) at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542) at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423) - locked <0x00000007b8d8e6f8> (a java.util.ArrayDeque) at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:232) {noformat} and {noformat} - waiting to lock <0x00000007b8d8e6f8> (a java.util.ArrayDeque) at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122) at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154) at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122) at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115) at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139) - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157) - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283) - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) at java.io.FilterOutputStream.close(FilterOutputStream.java:160) {noformat} Preferably locks should be obtained in the same order across the different code paths to prevent deadlocks. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 10:59:39 2014 From: issues at jboss.org (Peter Major (JIRA)) Date: Fri, 21 Nov 2014 10:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4113) 8.2.0.Final build hangs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Major updated WFLY-4113: ------------------------------ Attachment: jstack.txt The jstack that demonstrates the deadlock during the build. > 8.2.0.Final build hangs > ----------------------- > > Key: WFLY-4113 > URL: https://issues.jboss.org/browse/WFLY-4113 > Project: WildFly > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 8.2.0.Final > Reporter: Peter Major > Attachments: jstack.txt > > > When trying to build 8.2.0.Final locally, my build just hangs indefinitely while executing a unit test in the controller module: > {noformat} > Running org.jboss.as.controller.ModelControllerClientTestCase > {noformat} > Running jstack against the build suggests that there is a deadlock between > {noformat} > - waiting to lock <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) > at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423) > - locked <0x00000007b8d8e6f8> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:232) > {noformat} > and > {noformat} > - waiting to lock <0x00000007b8d8e6f8> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122) > at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154) > at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122) > at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115) > at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at java.io.FilterOutputStream.close(FilterOutputStream.java:160) > {noformat} > Preferably locks should be obtained in the same order across the different code paths to prevent deadlocks. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 11:02:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 21 Nov 2014 11:02:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4113) 8.2.0.Final build hangs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd reassigned WFLY-4113: --------------------------------- Assignee: David Lloyd > 8.2.0.Final build hangs > ----------------------- > > Key: WFLY-4113 > URL: https://issues.jboss.org/browse/WFLY-4113 > Project: WildFly > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 8.2.0.Final > Reporter: Peter Major > Assignee: David Lloyd > Attachments: jstack.txt > > > When trying to build 8.2.0.Final locally, my build just hangs indefinitely while executing a unit test in the controller module: > {noformat} > Running org.jboss.as.controller.ModelControllerClientTestCase > {noformat} > Running jstack against the build suggests that there is a deadlock between > {noformat} > - waiting to lock <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) > at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423) > - locked <0x00000007b8d8e6f8> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:232) > {noformat} > and > {noformat} > - waiting to lock <0x00000007b8d8e6f8> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122) > at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154) > at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122) > at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115) > at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at java.io.FilterOutputStream.close(FilterOutputStream.java:160) > {noformat} > Preferably locks should be obtained in the same order across the different code paths to prevent deadlocks. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 11:03:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 21 Nov 2014 11:03:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4113) 8.2.0.Final build hangs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021986#comment-13021986 ] David Lloyd commented on WFLY-4113: ----------------------------------- This looks like a regression, and it's probably my fault as this was probably re-introduced when I fixed the exceptions-on-close problem a couple weeks ago. > 8.2.0.Final build hangs > ----------------------- > > Key: WFLY-4113 > URL: https://issues.jboss.org/browse/WFLY-4113 > Project: WildFly > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 8.2.0.Final > Reporter: Peter Major > Assignee: David Lloyd > Attachments: jstack.txt > > > When trying to build 8.2.0.Final locally, my build just hangs indefinitely while executing a unit test in the controller module: > {noformat} > Running org.jboss.as.controller.ModelControllerClientTestCase > {noformat} > Running jstack against the build suggests that there is a deadlock between > {noformat} > - waiting to lock <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) > at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423) > - locked <0x00000007b8d8e6f8> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:232) > {noformat} > and > {noformat} > - waiting to lock <0x00000007b8d8e6f8> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122) > at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154) > at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122) > at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115) > at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at java.io.FilterOutputStream.close(FilterOutputStream.java:160) > {noformat} > Preferably locks should be obtained in the same order across the different code paths to prevent deadlocks. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 11:06:39 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Fri, 21 Nov 2014 11:06:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1238) removeIdleConnections should remove empty pools more aggressive In-Reply-To: References: Message-ID: Jesper Pedersen created JBJCA-1238: -------------------------------------- Summary: removeIdleConnections should remove empty pools more aggressive Key: JBJCA-1238 URL: https://issues.jboss.org/browse/JBJCA-1238 Project: IronJacamar Issue Type: Bug Components: Core Affects Versions: 1.2.0.Final, 1.1.9.Final, 1.0.30.Final Reporter: Jesper Pedersen Assignee: Jesper Pedersen Priority: Minor Fix For: 1.1.10.Final, 1.2.1.Final Pools where flush() has been called are affected -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 11:10:39 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 21 Nov 2014 11:10:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4113) 8.2.0.Final build hangs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021991#comment-13021991 ] James Perkins commented on WFLY-4113: ------------------------------------- Thread dump from a local hang {code} "Remoting "endpoint" task-10": at org.jboss.remoting3.remote.OutboundMessage.cancel(OutboundMessage.java:289) - waiting to lock <0x00000007aed930d8> (a org.xnio.streams.BufferPipeOutputStream) at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560) at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542) at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423) - locked <0x00000007aec0f708> (a java.util.ArrayDeque) at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest( RemoteConnectionHandler.java:232) at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:112) at org.jboss.remoting3.remote.RemoteReadListener$1$1.run(RemoteReadListener.java:56) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) "Remoting 3 thread 1": at org.jboss.remoting3.remote.RemoteConnection$RemoteWriteListener.send(RemoteConnection.java:295) - waiting to lock <0x00000007aec0f708> (a java.util.ArrayDeque) at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122) at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154) at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122) at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115) at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139) - locked <0x00000007aed930d8> (a org.xnio.streams.BufferPipeOutputStream) at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157) - locked <0x00000007aed930d8> (a org.xnio.streams.BufferPipeOutputStream) at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283) - locked <0x00000007aed930d8> (a org.xnio.streams.BufferPipeOutputStream) at java.io.FilterOutputStream.close(FilterOutputStream.java:160) at org.jboss.as.protocol.mgmt.FlushableDataOutputImpl.close(FlushableDataOutputImpl.java:123) at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$CancelAsyncRequestHandler$1.execute(ModelControllerClientOperationHandler.java:296) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:283) at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:504) at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33) at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808) at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45) at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:122) {code} The deadlock seems to be happening on https://github.com/jamezp/wildfly/blob/8.x/controller/src/test/java/org/jboss/as/controller/support/RemoteChannelPairSetup.java#L128-128 for me. > 8.2.0.Final build hangs > ----------------------- > > Key: WFLY-4113 > URL: https://issues.jboss.org/browse/WFLY-4113 > Project: WildFly > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 8.2.0.Final > Reporter: Peter Major > Assignee: David Lloyd > Attachments: jstack.txt > > > When trying to build 8.2.0.Final locally, my build just hangs indefinitely while executing a unit test in the controller module: > {noformat} > Running org.jboss.as.controller.ModelControllerClientTestCase > {noformat} > Running jstack against the build suggests that there is a deadlock between > {noformat} > - waiting to lock <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeMessages(RemoteConnectionChannel.java:560) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:542) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) > at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:423) > - locked <0x00000007b8d8e6f8> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnectionHandler.sendCloseRequest(RemoteConnectionHandler.java:232) > {noformat} > and > {noformat} > - waiting to lock <0x00000007b8d8e6f8> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnection.send(RemoteConnection.java:122) > at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:154) > at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:122) > at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:115) > at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:139) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:157) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:283) > - locked <0x00000007bc3f96c8> (a org.xnio.streams.BufferPipeOutputStream) > at java.io.FilterOutputStream.close(FilterOutputStream.java:160) > {noformat} > Preferably locks should be obtained in the same order across the different code paths to prevent deadlocks. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 11:19:40 2014 From: issues at jboss.org (Jesper Pedersen (JIRA)) Date: Fri, 21 Nov 2014 11:19:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1238) removeIdleConnections should remove empty pools more aggressive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesper Pedersen resolved JBJCA-1238. ------------------------------------ Resolution: Done > removeIdleConnections should remove empty pools more aggressive > --------------------------------------------------------------- > > Key: JBJCA-1238 > URL: https://issues.jboss.org/browse/JBJCA-1238 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.30.Final, 1.1.9.Final, 1.2.0.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Minor > Fix For: 1.1.10.Final, 1.2.1.Final > > > Pools where flush() has been called are affected -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 11:34:40 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 21 Nov 2014 11:34:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-870) Release JBoss Negotiation 2.3.5.Final In-Reply-To: References: Message-ID: Darran Lofthouse created SECURITY-870: ----------------------------------------- Summary: Release JBoss Negotiation 2.3.5.Final Key: SECURITY-870 URL: https://issues.jboss.org/browse/SECURITY-870 Project: PicketBox Issue Type: Release Components: Negotiation Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: Negotiation_2_3_5.Final -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 11:42:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Fri, 21 Nov 2014 11:42:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4111) Unable to read web-application files using ServletContext.getResourceAsStream when security manager is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022014#comment-13022014 ] David Lloyd commented on WFLY-4111: ----------------------------------- This commit *should* fix the deadlock: https://github.com/jboss-remoting/jboss-remoting/commit/afd95bbf3b2 > Unable to read web-application files using ServletContext.getResourceAsStream when security manager is used > ----------------------------------------------------------------------------------------------------------- > > Key: WFLY-4111 > URL: https://issues.jboss.org/browse/WFLY-4111 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > > Servlets should be able to read application files by using ServletContext.getResourceAsStream without specifying additional permissions. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:10:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 12:10:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1650) Legacy subsystem testing needs some classloading exclusion mecanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022032#comment-13022032 ] RH Bugzilla Integration commented on WFLY-1650: ----------------------------------------------- Emmanuel Hugonnet (ehsavoie) changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from ASSIGNED to POST > Legacy subsystem testing needs some classloading exclusion mecanism > ------------------------------------------------------------------- > > Key: WFLY-1650 > URL: https://issues.jboss.org/browse/WFLY-1650 > Project: WildFly > Issue Type: Bug > Components: Logging, Test Suite > Affects Versions: 8.0.0.Alpha3 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Fix For: 8.0.0.Beta1 > > > When translation messages are used (which is the case of EAP) we have conflicts between generated $logger classes when testing submodules. > Some $logger classes exis thus they are loaded by the parent classloader before the childfirstclassloader tries to load them, thus we have a potential ClassCastException brewing. > For exemple this breaks the EAP build on a French OS. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:10:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 12:10:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-134) Make sure CLIWrapper doesn't use default encoding In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022033#comment-13022033 ] RH Bugzilla Integration commented on WFCORE-134: ------------------------------------------------ Emmanuel Hugonnet (ehsavoie) changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from ASSIGNED to POST > Make sure CLIWrapper doesn't use default encoding > ------------------------------------------------- > > Key: WFCORE-134 > URL: https://issues.jboss.org/browse/WFCORE-134 > Project: WildFly Core > Issue Type: Bug > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > CLIWrapper is using the default encoding which might lead to issue with non US locales. > Also take advantage of this fix to remove some hard coded strings from tests. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:10:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 12:10:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (REMJMX-86) RemotingConnector & VersionedConectionFactory need configurable connection, channel & versioned connection timeouts In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/REMJMX-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated REMJMX-86: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1113247, https://bugzilla.redhat.com/show_bug.cgi?id=1113242, https://bugzilla.redhat.com/show_bug.cgi?id=1113252, https://bugzilla.redhat.com/show_bug.cgi?id=1166839 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1113247, https://bugzilla.redhat.com/show_bug.cgi?id=1113242, https://bugzilla.redhat.com/show_bug.cgi?id=1113252) > RemotingConnector & VersionedConectionFactory need configurable connection, channel & versioned connection timeouts > -------------------------------------------------------------------------------------------------------------------- > > Key: REMJMX-86 > URL: https://issues.jboss.org/browse/REMJMX-86 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 2.0.0.Final > Reporter: Mustafa Musaji > Assignee: Brad Maxwell > Fix For: 1.1.3.Final, 2.0.1.CR1 > > > In [1] we have the following snippet of code which has a hardcoded value of 5 seconds. > {code:title=RemotingConnector.java} > // Now open the channel > final IoFuture futureChannel = connection.openChannel(serviceName, OptionMap.EMPTY); > IoFuture.Status result = futureChannel.await(5, TimeUnit.SECONDS); > if (result == IoFuture.Status.DONE) { > channel = futureChannel.get(); > } else if (result == IoFuture.Status.FAILED) { > throw new IOException(futureChannel.getException()); > } else { > throw new RuntimeException("Operation failed with status " + result); > } > {code} > This should be a system property or the default value should be raised. > [1] https://github.com/jbossas/remoting-jmx/blob/master/src/main/java/org/jboss/remotingjmx/RemotingConnector.java -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:15:40 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 21 Nov 2014 12:15:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-274) The CLI command "read-boot-errors" does not include the timestamp of the error event In-Reply-To: References: Message-ID: Emmanuel Hugonnet created WFCORE-274: ---------------------------------------- Summary: The CLI command "read-boot-errors" does not include the timestamp of the error event Key: WFCORE-274 URL: https://issues.jboss.org/browse/WFCORE-274 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Affects Versions: 1.0.0.Alpha13 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet The CLI command "read-boot-errors" does not include the timestamp of the error event. For anyone using this command for diagnostic purposes, the absence of an event's timestamp decreases the usefulness of the information. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:16:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 12:16:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-274) The CLI command "read-boot-errors" does not include the timestamp of the error event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-274: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1160898 > The CLI command "read-boot-errors" does not include the timestamp of the error event > ------------------------------------------------------------------------------------ > > Key: WFCORE-274 > URL: https://issues.jboss.org/browse/WFCORE-274 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > The CLI command "read-boot-errors" does not include the timestamp of the error event. For anyone using this command for diagnostic purposes, the absence of an event's timestamp decreases the usefulness of the information. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:16:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 12:16:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-274) The CLI command "read-boot-errors" does not include the timestamp of the error event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022034#comment-13022034 ] RH Bugzilla Integration commented on WFCORE-274: ------------------------------------------------ Emmanuel Hugonnet (ehsavoie) changed the Status of [bug 1160898|https://bugzilla.redhat.com/show_bug.cgi?id=1160898] from NEW to ASSIGNED > The CLI command "read-boot-errors" does not include the timestamp of the error event > ------------------------------------------------------------------------------------ > > Key: WFCORE-274 > URL: https://issues.jboss.org/browse/WFCORE-274 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > The CLI command "read-boot-errors" does not include the timestamp of the error event. For anyone using this command for diagnostic purposes, the absence of an event's timestamp decreases the usefulness of the information. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:26:40 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Fri, 21 Nov 2014 12:26:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-275) Migrate soem RBAC test from WildFly full to WFCORE In-Reply-To: References: Message-ID: Emmanuel Hugonnet created WFCORE-275: ---------------------------------------- Summary: Migrate soem RBAC test from WildFly full to WFCORE Key: WFCORE-275 URL: https://issues.jboss.org/browse/WFCORE-275 Project: WildFly Core Issue Type: Task Components: Test Suite Affects Versions: 1.0.0.Alpha13 Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet All RBAC integration testing is currently done in the WILDFLY project whereas the code is in WFCORE. Migrate some tests which are not related to the RBAC usage in WILDFLY to WFCORE. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:38:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 21 Nov 2014 12:38:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-869) Session created if it doesn't exist even if authentication does not occur. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved SECURITY-869. --------------------------------------- Resolution: Done > Session created if it doesn't exist even if authentication does not occur. > -------------------------------------------------------------------------- > > Key: SECURITY-869 > URL: https://issues.jboss.org/browse/SECURITY-869 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_5.Final > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:47:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 21 Nov 2014 12:47:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4114) Upgrade to JBoss Negotiation 2.3.5.Final In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-4114: -------------------------------------- Summary: Upgrade to JBoss Negotiation 2.3.5.Final Key: WFLY-4114 URL: https://issues.jboss.org/browse/WFLY-4114 Project: WildFly Issue Type: Component Upgrade Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:48:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 21 Nov 2014 12:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-870) Release JBoss Negotiation 2.3.5.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved SECURITY-870. --------------------------------------- Resolution: Done > Release JBoss Negotiation 2.3.5.Final > ------------------------------------- > > Key: SECURITY-870 > URL: https://issues.jboss.org/browse/SECURITY-870 > Project: PicketBox > Issue Type: Release > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_3_5.Final > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:51:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 21 Nov 2014 12:51:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-822) Remove the 'NET' project from JBoss Negotiation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated SECURITY-822: -------------------------------------- Fix Version/s: Negotiation_2_3_6_Final (was: Negotiation_2_3_5.Final) > Remove the 'NET' project from JBoss Negotiation > ----------------------------------------------- > > Key: SECURITY-822 > URL: https://issues.jboss.org/browse/SECURITY-822 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_11, Negotiation_2_3_6_Final > > > The net project is not used in AS 7, EAP 6 or WildFly so time to delete it. > In WildFly 9 an alternative SASL based approach will be used for EJB invocations. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 12:55:39 2014 From: issues at jboss.org (Eduardo Martins (JIRA)) Date: Fri, 21 Nov 2014 12:55:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4112) Update Wildfly JDF Stacks (BOM) for 8.2.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eduardo Martins reassigned WFLY-4112: ------------------------------------- Assignee: Eduardo Martins (was: Tomaz Cerar) > Update Wildfly JDF Stacks (BOM) for 8.2.0.Final > ----------------------------------------------- > > Key: WFLY-4112 > URL: https://issues.jboss.org/browse/WFLY-4112 > Project: WildFly > Issue Type: Feature Request > Affects Versions: 8.2.0.Final > Reporter: Cody Lerum > Assignee: Eduardo Martins > > The JDF stacks haven't been updated for Wildfly 8.2.0.Final > This creates an issue for users wishing to keep the provided impl versions in sync with their project for debugging purposes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 13:35:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Fri, 21 Nov 2014 13:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-276) whoami operation failed when rbac enabled but no roles assigned In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-276: --------------------------------------- Summary: whoami operation failed when rbac enabled but no roles assigned Key: WFCORE-276 URL: https://issues.jboss.org/browse/WFCORE-276 Project: WildFly Core Issue Type: Bug Components: CLI, Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha14 Need to double check this is either the CLI making a call in addition to the whoami op and that call is failing or something being accessed by whoami is causing the failure. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 15:01:39 2014 From: issues at jboss.org (Harald Wellmann (JIRA)) Date: Fri, 21 Nov 2014 15:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4115) WildFly 8.2.0.Final Maven artifacts are incomplete In-Reply-To: References: Message-ID: Harald Wellmann created WFLY-4115: ------------------------------------- Summary: WildFly 8.2.0.Final Maven artifacts are incomplete Key: WFLY-4115 URL: https://issues.jboss.org/browse/WFLY-4115 Project: WildFly Issue Type: Bug Affects Versions: 8.2.0.Final Reporter: Harald Wellmann Assignee: Jason Greene WildFly 8.2.0.Final artifacts in {{https://repository.jboss.org/nexus/content/repositories/releases}} are incomplete. E.g. wildfly-embedded has a POM but no JARs. wildfly-jaxrs has a JAR but no POM. On Maven Central, there are neither JARs nor POMs for these two artifacts. wildfly-dist seems to be the only one that has made it to Central up to now. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 15:19:39 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 21 Nov 2014 15:19:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4115) WildFly 8.2.0.Final Maven artifacts are incomplete In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022092#comment-13022092 ] James Perkins commented on WFLY-4115: ------------------------------------- Looks like the JAR is there to me https://repository.jboss.org/nexus/content/repositories/releases/org/wildfly/wildfly-embedded/8.2.0.Final/. JAX-RS is missing the pom. As far as Maven Central that is synced a few times a day. Once a sync runs it should be on Maven Central. > WildFly 8.2.0.Final Maven artifacts are incomplete > -------------------------------------------------- > > Key: WFLY-4115 > URL: https://issues.jboss.org/browse/WFLY-4115 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Reporter: Harald Wellmann > Assignee: Jason Greene > > WildFly 8.2.0.Final artifacts in > {{https://repository.jboss.org/nexus/content/repositories/releases}} > are incomplete. > E.g. wildfly-embedded has a POM but no JARs. > wildfly-jaxrs has a JAR but no POM. > On Maven Central, there are neither JARs nor POMs for these two artifacts. wildfly-dist seems to be the only one that has made it to Central up to now. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 15:43:39 2014 From: issues at jboss.org (sathiya seelan (JIRA)) Date: Fri, 21 Nov 2014 15:43:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1154) Allow the server to ignore files or groups of files at deployment time In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022095#comment-13022095 ] sathiya seelan commented on WFLY-1154: -------------------------------------- Hi folks, I want to start working on this issue. What is the procedure or How to get start working? Thanks > Allow the server to ignore files or groups of files at deployment time > ---------------------------------------------------------------------- > > Key: WFLY-1154 > URL: https://issues.jboss.org/browse/WFLY-1154 > Project: WildFly > Issue Type: Feature Request > Components: Server > Reporter: Marius Bogoevici > Fix For: Awaiting Volunteers > > > Legacy and migrated applications may occasionally contain files which are incompatible with the Java EE specification and can cause the application to fail the deployment. The difference between those cases and really faulty Java EE applications lies in the intent of the developer - whether they wish for those files to be picked up by the server and processed, or not. > In such cases, it may be useful to expand the deployment specification and to be able to instruct the server to ignore particular files at deployment time. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 19:01:40 2014 From: issues at jboss.org (Lars Hellgren (JIRA)) Date: Fri, 21 Nov 2014 19:01:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4116) WAR deployment fails on missing security domain dependency In-Reply-To: References: Message-ID: Lars Hellgren created WFLY-4116: ----------------------------------- Summary: WAR deployment fails on missing security domain dependency Key: WFLY-4116 URL: https://issues.jboss.org/browse/WFLY-4116 Project: WildFly Issue Type: Feature Request Components: Security, Web (JBoss Web), Web (Undertow) Affects Versions: 8.2.0.Final Environment: Standalone form-based authentication WAR Reporter: Lars Hellgren Assignee: Darran Lofthouse Fix For: 8.2.0.Final Moving WARs using form based authentication from WildFly 8.1 Final to 8.2 Final fails due to a missing security domain dependency. *Log* {noformat} service jboss.security.security-domain.java:/jaas/haa-portal (missing) dependents: [service jboss.deployment.unit."haa-security-manager.war".component.SecurityManagerRepositorySessionBean.CREATE, service jboss.deployment.unit."haa-security-manager.war".component.UserPrefsRepository.CREATE] {noformat} *jboss-web.xml* {code:xml} java:/jaas/haa-portal {code} *standalone.xml* {code:xml} ... ... {code} The datasource is deployed and connected. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 19:35:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 19:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3285) Domain directory properties only work on specific operating systems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022120#comment-13022120 ] RH Bugzilla Integration commented on WFLY-3285: ----------------------------------------------- James Perkins changed the Status of [bug 1091198|https://bugzilla.redhat.com/show_bug.cgi?id=1091198] from ASSIGNED to POST > Domain directory properties only work on specific operating systems > ------------------------------------------------------------------- > > Key: WFLY-3285 > URL: https://issues.jboss.org/browse/WFLY-3285 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.1.0.CR1 > Reporter: Dennis Reed > Assignee: Tomaz Cerar > > domain.sh only parses -Djboss.domain.base.dir, -Djboss.domain.log.dir, and -Djboss.domain.config.dir (used to set -Dlogging.configuration and -Dorg.jboss.boot.log.file) on Linux, Solaris, and OS X. > It does not attempt to parse these (and therefore does not set the logging properties correctly) on any other OS, including AIX. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 21 19:35:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 21 Nov 2014 19:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022121#comment-13022121 ] RH Bugzilla Integration commented on WFCORE-160: ------------------------------------------------ James Perkins changed the Status of [bug 1145960|https://bugzilla.redhat.com/show_bug.cgi?id=1145960] from ASSIGNED to POST > Bash scripts should not attempt to expand argument properties > ------------------------------------------------------------- > > Key: WFCORE-160 > URL: https://issues.jboss.org/browse/WFCORE-160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha10 > > > Scripts that parse the command line arguments use a pattern like > {code} > while [ "$#" -gt 0 ] > do > case "$1" in > *) > CLI_OPTS="$CLI_OPTS \"$1\"" > ;; > esac > shift > done > {code} > The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 22 00:23:39 2014 From: issues at jboss.org (jaikiran pai (JIRA)) Date: Sat, 22 Nov 2014 00:23:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4116) WAR deployment fails on missing security domain dependency In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022124#comment-13022124 ] jaikiran pai commented on WFLY-4116: ------------------------------------ The security-domain you have defined in your jboss-web.xml is incorrect. It should just be the name of the security domain. Change it to: {code} haa-portal {code} > WAR deployment fails on missing security domain dependency > ---------------------------------------------------------- > > Key: WFLY-4116 > URL: https://issues.jboss.org/browse/WFLY-4116 > Project: WildFly > Issue Type: Feature Request > Components: Security, Web (JBoss Web), Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Standalone form-based authentication WAR > Reporter: Lars Hellgren > Assignee: Darran Lofthouse > Fix For: 8.2.0.Final > > > Moving WARs using form based authentication from WildFly 8.1 Final to 8.2 Final fails due to a missing security domain dependency. > *Log* > {noformat} > service jboss.security.security-domain.java:/jaas/haa-portal (missing) dependents: > [service jboss.deployment.unit."haa-security-manager.war".component.SecurityManagerRepositorySessionBean.CREATE, > service jboss.deployment.unit."haa-security-manager.war".component.UserPrefsRepository.CREATE] > {noformat} > *jboss-web.xml* > {code:xml} > > java:/jaas/haa-portal > > {code} > *standalone.xml* > {code:xml} > > > ... > > > > ... > > > > > > {code} > The datasource is deployed and connected. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 22 05:35:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sat, 22 Nov 2014 05:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-733) Session replication broken by NegotiationAuthenticator valve In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022132#comment-13022132 ] RH Bugzilla Integration commented on SECURITY-733: -------------------------------------------------- Kabir Khan changed the Status of [bug 949737|https://bugzilla.redhat.com/show_bug.cgi?id=949737] from ASSIGNED to ON_QA > Session replication broken by NegotiationAuthenticator valve > ------------------------------------------------------------ > > Key: SECURITY-733 > URL: https://issues.jboss.org/browse/SECURITY-733 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_2_2_2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_3 > > > From an initial review of the code I believe this is because the ClusterSessionValve implements the Listener interface - however the wrapper class does not. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 22 05:46:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sat, 22 Nov 2014 05:46:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1650) Legacy subsystem testing needs some classloading exclusion mecanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022133#comment-13022133 ] RH Bugzilla Integration commented on WFLY-1650: ----------------------------------------------- Kabir Khan changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from POST to MODIFIED > Legacy subsystem testing needs some classloading exclusion mecanism > ------------------------------------------------------------------- > > Key: WFLY-1650 > URL: https://issues.jboss.org/browse/WFLY-1650 > Project: WildFly > Issue Type: Bug > Components: Logging, Test Suite > Affects Versions: 8.0.0.Alpha3 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Fix For: 8.0.0.Beta1 > > > When translation messages are used (which is the case of EAP) we have conflicts between generated $logger classes when testing submodules. > Some $logger classes exis thus they are loaded by the parent classloader before the childfirstclassloader tries to load them, thus we have a potential ClassCastException brewing. > For exemple this breaks the EAP build on a French OS. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 22 05:46:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sat, 22 Nov 2014 05:46:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-134) Make sure CLIWrapper doesn't use default encoding In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022134#comment-13022134 ] RH Bugzilla Integration commented on WFCORE-134: ------------------------------------------------ Kabir Khan changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from POST to MODIFIED > Make sure CLIWrapper doesn't use default encoding > ------------------------------------------------- > > Key: WFCORE-134 > URL: https://issues.jboss.org/browse/WFCORE-134 > Project: WildFly Core > Issue Type: Bug > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > CLIWrapper is using the default encoding which might lead to issue with non US locales. > Also take advantage of this fix to remove some hard coded strings from tests. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 22 05:49:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sat, 22 Nov 2014 05:49:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4110) EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022135#comment-13022135 ] RH Bugzilla Integration commented on WFLY-4110: ----------------------------------------------- Kabir Khan changed the Status of [bug 1164231|https://bugzilla.redhat.com/show_bug.cgi?id=1164231] from POST to MODIFIED > EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used > --------------------------------------------------------------------------------------- > > Key: WFLY-4110 > URL: https://issues.jboss.org/browse/WFLY-4110 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: Dominik Pospisil > Assignee: Dominik Pospisil > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 22 05:50:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sat, 22 Nov 2014 05:50:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4109) Remove outdated policy files from testsuite/integration/src/test/config In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022136#comment-13022136 ] RH Bugzilla Integration commented on WFLY-4109: ----------------------------------------------- Kabir Khan changed the Status of [bug 1166130|https://bugzilla.redhat.com/show_bug.cgi?id=1166130] from POST to MODIFIED > Remove outdated policy files from testsuite/integration/src/test/config > ----------------------------------------------------------------------- > > Key: WFLY-4109 > URL: https://issues.jboss.org/browse/WFLY-4109 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Minor > > Policy files no-op.policy and permit_all_testsuite.policy are outdated. They should be removed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 22 08:11:39 2014 From: issues at jboss.org (Gabor Auth (JIRA)) Date: Sat, 22 Nov 2014 08:11:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3718) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022141#comment-13022141 ] Gabor Auth commented on WFLY-3718: ---------------------------------- I've downloaded the source of the 8.1.0-Final, applied the "patch" on the SimpleImmutableSessionAttributes.java class as described in the WFLY-3345 issue, replaced the original wildfly-clustering-web-infinispan-8.1.0.Final.jar with the patched one, and the issue still exists... :( > UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-3718 > URL: https://issues.jboss.org/browse/WFLY-3718 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: WildFly 8.1.0.Final > Reporter: Gabor Auth > Assignee: Paul Ferraro > Fix For: 8.2.0.Final > > > 2014-07-30 02:12:30,088 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException > at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164) > at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11] > 2014-07-30 02:12:30,786 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /frontend/images/favicon.ico}: java.lang.NullPointerException > at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164) > at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) > at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:711) > at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:137) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11] -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 22 10:20:39 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Sat, 22 Nov 2014 10:20:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-238) A call to a default method In-Reply-To: References: Message-ID: Shigeru Chiba created JASSIST-238: ------------------------------------- Summary: A call to a default method Key: JASSIST-238 URL: https://issues.jboss.org/browse/JASSIST-238 Project: Javassist Issue Type: Feature Request Affects Versions: 3.18.2-GA Reporter: Shigeru Chiba Assignee: Shigeru Chiba Fix For: 3.19.0-GA CtBehavior#setBody() etc. does accept source code containing a call to a default method declared in an interface. Original post: https://github.com/jboss-javassist/javassist/issues/22 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 22 10:24:39 2014 From: issues at jboss.org (Alfio Gloria (JIRA)) Date: Sat, 22 Nov 2014 10:24:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBASMP-68) execute-commands does not work for module command In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBASMP-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022142#comment-13022142 ] Alfio Gloria commented on JBASMP-68: ------------------------------------ Hi Ram, It's just a workaround that fit my needs. I simply replaced each occurrence of SecurityActions.getEnvironmentVariable(JBOSS_HOME) in the jboss-cli project with SecurityActions.getSystemProperty("cli_jboss_home") Affected classes are: org.jboss.as.cli.handlers.module.ASModuleHandler, org.jboss.as.cli.handlers.VersionHandler and org.jboss.as.cli.impl.CliConfigImpl Then in the execute method of ExceuteCommand Mojo i added: if(jbossHome != null) { System.setProperty("cli_jboss_home", jbossHome); } > execute-commands does not work for module command > ------------------------------------------------- > > Key: JBASMP-68 > URL: https://issues.jboss.org/browse/JBASMP-68 > Project: JBoss AS Maven Plugins > Issue Type: Bug > Affects Versions: 7.6.Final > Reporter: Alfio Gloria > Assignee: James Perkins > > I'm trying to remove a jboss module by means of maven. > {code:xml} > > ${project.build.directory}/server/jboss72 > > > module remove --slot=main --name=system.layers.base.org.jboss.weld.core > > > > {code} > execute-commands fails with the following stack trace: > {code} > Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > 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:483) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > ... 19 more > Caused by: java.lang.IllegalArgumentException: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. > at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:180) > at org.jboss.as.plugin.cli.Commands.execute(Commands.java:134) > at org.jboss.as.plugin.cli.ExecuteCommands.execute(ExecuteCommands.java:71) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > ... 20 more > Caused by: org.jboss.as.cli.CommandLineException: JBOSS_HOME environment variable is not set. > at org.jboss.as.cli.handlers.module.ASModuleHandler.getModulesDir(ASModuleHandler.java:362) > at org.jboss.as.cli.handlers.module.ASModuleHandler.removeModule(ASModuleHandler.java:326) > at org.jboss.as.cli.handlers.module.ASModuleHandler.doHandle(ASModuleHandler.java:214) > at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86) > at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:581) > at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:176) > ... 23 more > {code} > (tested with the last snapshot too) > The problem comes from jboss-as-cli that needs the JBOSS_HOME to be set in order to add or remove modules. This is not a requirement for other commands such as deploy. > There are some points of confusion: > # JBOSS_HOME is set in .bashrc but IDEs do not read .bashrc, thereby it can work in some cases but not in others; > # usually there are more than one installation or jboss-as-maven-plugin can download the server; > # jbossHome config parameter is not take into account; > # what if I want to make operations on more the one server at the same time? > At the moment I solved by patching jboss-as-cli using a system property instead of environment variable. I don't know how to solve without touching jboss-as-cli. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 22 10:41:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sat, 22 Nov 2014 10:41:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBTEST-21) Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTEST-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022143#comment-13022143 ] RH Bugzilla Integration commented on JBTEST-21: ----------------------------------------------- Panagiotis Sotiropoulos changed the Status of [bug 1100839|https://bugzilla.redhat.com/show_bug.cgi?id=1100839] from ASSIGNED to POST > Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 > -------------------------------------------------------------------- > > Key: JBTEST-21 > URL: https://issues.jboss.org/browse/JBTEST-21 > Project: JBoss Test > Issue Type: Bug > Environment: IBM JDK > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > When test DataSourceOperationsUnitTestCase is build with IBM JDK 1.6 it fails with error : > Tests in error: > org.jboss.as.test.smoke.mgmt.datasource.DataSourceOperationsUnitTestCase: [SHRINKWRAP-93] Cannot use this JDK-based implementation to export as ZIP an archive with no content: 314225ff-6abf-4453-b69b-7dd12b707d65.jar: 0 assets > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 22 11:09:39 2014 From: issues at jboss.org (Shigeru Chiba (JIRA)) Date: Sat, 22 Nov 2014 11:09:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JASSIST-238) A call to a default method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JASSIST-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shigeru Chiba closed JASSIST-238. --------------------------------- Resolution: Done > A call to a default method > -------------------------- > > Key: JASSIST-238 > URL: https://issues.jboss.org/browse/JASSIST-238 > Project: Javassist > Issue Type: Feature Request > Affects Versions: 3.18.2-GA > Reporter: Shigeru Chiba > Assignee: Shigeru Chiba > Fix For: 3.19.0-GA > > > CtBehavior#setBody() etc. does accept source code containing a call to a default method declared in an interface. > Original post: > https://github.com/jboss-javassist/javassist/issues/22 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 23 12:38:40 2014 From: issues at jboss.org (sathiya seelan (JIRA)) Date: Sun, 23 Nov 2014 12:38:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1192) jboss-deployment-structure.xml top level exclusion does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022159#comment-13022159 ] sathiya seelan commented on WFLY-1192: -------------------------------------- Hi I'm interested to start working on this issue. Can anyone please help me to get started? Thanks in advance. Sathya > jboss-deployment-structure.xml top level exclusion does not work > ---------------------------------------------------------------- > > Key: WFLY-1192 > URL: https://issues.jboss.org/browse/WFLY-1192 > Project: WildFly > Issue Type: Feature Request > Components: Class Loading > Environment: Windows, RedHat Linux > Reporter: Markus Lindblom > Fix For: Awaiting Volunteers > > > When I try to exclude for example Log4J in the deployment structure I have to exclude it from every subdeployment in the deployment structure file, the top level exclusion should exclude it from the entire EAR and all of its subdeployments. > Ed: The feature request is, to add a convenient way to cause exclusions to cascade to subdeployments. Right now it works per design. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 23 22:32:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 23 Nov 2014 22:32:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-277) Support nested expressions in deployment descriptors In-Reply-To: References: Message-ID: Brian Stansberry created WFCORE-277: --------------------------------------- Summary: Support nested expressions in deployment descriptors Key: WFCORE-277 URL: https://issues.jboss.org/browse/WFCORE-277 Project: WildFly Core Issue Type: Feature Request Reporter: Brian Stansberry Assignee: Brian Stansberry Users have requested support for expressions such as: {code} ${VAULT::oracle::${me}::0} {code} where "me" is a system property. Allows externalization of the vault attribute name. This will likely require JBMETA changes as well, as the deployment level stuff is there. I want this to be a generic thing, not just a specific solution to the above example. So, something like, given a string, find the innermost expression, resolve it and then repeat until the input equals the output (i.e. there are no more expressions.) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 23 22:32:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 23 Nov 2014 22:32:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4117) Support nested expressions in deployment descriptors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved WFCORE-277 to WFLY-4117: ----------------------------------------------- Project: WildFly (was: WildFly Core) Key: WFLY-4117 (was: WFCORE-277) > Support nested expressions in deployment descriptors > ---------------------------------------------------- > > Key: WFLY-4117 > URL: https://issues.jboss.org/browse/WFLY-4117 > Project: WildFly > Issue Type: Feature Request > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Users have requested support for expressions such as: > {code} > ${VAULT::oracle::${me}::0} > {code} > where "me" is a system property. > Allows externalization of the vault attribute name. > This will likely require JBMETA changes as well, as the deployment level stuff is there. > I want this to be a generic thing, not just a specific solution to the above example. So, something like, given a string, find the innermost expression, resolve it and then repeat until the input equals the output (i.e. there are no more expressions.) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sun Nov 23 22:33:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Sun, 23 Nov 2014 22:33:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4117) Support nested expressions in deployment descriptors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFLY-4117: ----------------------------------- Description: Deployment descriptor aspect of WFCORE-179. Users have requested support for expressions such as: {code} ${VAULT::oracle::${me}::0} {code} where "me" is a system property. Allows externalization of the vault attribute name. This will likely require JBMETA changes as well, as the deployment level stuff is there. I want this to be a generic thing, not just a specific solution to the above example. So, something like, given a string, find the innermost expression, resolve it and then repeat until the input equals the output (i.e. there are no more expressions.) was: Users have requested support for expressions such as: {code} ${VAULT::oracle::${me}::0} {code} where "me" is a system property. Allows externalization of the vault attribute name. This will likely require JBMETA changes as well, as the deployment level stuff is there. I want this to be a generic thing, not just a specific solution to the above example. So, something like, given a string, find the innermost expression, resolve it and then repeat until the input equals the output (i.e. there are no more expressions.) > Support nested expressions in deployment descriptors > ---------------------------------------------------- > > Key: WFLY-4117 > URL: https://issues.jboss.org/browse/WFLY-4117 > Project: WildFly > Issue Type: Feature Request > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > Deployment descriptor aspect of WFCORE-179. > Users have requested support for expressions such as: > {code} > ${VAULT::oracle::${me}::0} > {code} > where "me" is a system property. > Allows externalization of the vault attribute name. > This will likely require JBMETA changes as well, as the deployment level stuff is there. > I want this to be a generic thing, not just a specific solution to the above example. So, something like, given a string, find the innermost expression, resolve it and then repeat until the input equals the output (i.e. there are no more expressions.) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 01:36:39 2014 From: issues at jboss.org (Ram S (JIRA)) Date: Mon, 24 Nov 2014 01:36:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBASMP-68) execute-commands does not work for module command In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBASMP-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022186#comment-13022186 ] Ram S commented on JBASMP-68: ----------------------------- Thanks Alfio. > execute-commands does not work for module command > ------------------------------------------------- > > Key: JBASMP-68 > URL: https://issues.jboss.org/browse/JBASMP-68 > Project: JBoss AS Maven Plugins > Issue Type: Bug > Affects Versions: 7.6.Final > Reporter: Alfio Gloria > Assignee: James Perkins > > I'm trying to remove a jboss module by means of maven. > {code:xml} > > ${project.build.directory}/server/jboss72 > > > module remove --slot=main --name=system.layers.base.org.jboss.weld.core > > > > {code} > execute-commands fails with the following stack trace: > {code} > Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands (install-patched-weld) on project tools: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) > 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:483) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution install-patched-weld of goal org.jboss.as.plugins:jboss-as-maven-plugin:7.5.Final:execute-commands failed: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) > ... 19 more > Caused by: java.lang.IllegalArgumentException: Command execution failed for command 'module remove --slot=main --name=system.layers.base.org.jboss.weld.core'. JBOSS_HOME environment variable is not set. > at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:180) > at org.jboss.as.plugin.cli.Commands.execute(Commands.java:134) > at org.jboss.as.plugin.cli.ExecuteCommands.execute(ExecuteCommands.java:71) > at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) > ... 20 more > Caused by: org.jboss.as.cli.CommandLineException: JBOSS_HOME environment variable is not set. > at org.jboss.as.cli.handlers.module.ASModuleHandler.getModulesDir(ASModuleHandler.java:362) > at org.jboss.as.cli.handlers.module.ASModuleHandler.removeModule(ASModuleHandler.java:326) > at org.jboss.as.cli.handlers.module.ASModuleHandler.doHandle(ASModuleHandler.java:214) > at org.jboss.as.cli.handlers.CommandHandlerWithHelp.handle(CommandHandlerWithHelp.java:86) > at org.jboss.as.cli.impl.CommandContextImpl.handle(CommandContextImpl.java:581) > at org.jboss.as.plugin.cli.Commands.executeCommands(Commands.java:176) > ... 23 more > {code} > (tested with the last snapshot too) > The problem comes from jboss-as-cli that needs the JBOSS_HOME to be set in order to add or remove modules. This is not a requirement for other commands such as deploy. > There are some points of confusion: > # JBOSS_HOME is set in .bashrc but IDEs do not read .bashrc, thereby it can work in some cases but not in others; > # usually there are more than one installation or jboss-as-maven-plugin can download the server; > # jbossHome config parameter is not take into account; > # what if I want to make operations on more the one server at the same time? > At the moment I solved by patching jboss-as-cli using a system property instead of environment variable. I don't know how to solve without touching jboss-as-cli. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 02:08:39 2014 From: issues at jboss.org (jaikiran pai (JIRA)) Date: Mon, 24 Nov 2014 02:08:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3718) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022187#comment-13022187 ] jaikiran pai commented on WFLY-3718: ------------------------------------ WildFly 8.2.0.Final has been recently released http://wildfly.org/downloads/. Download it and give it a try against that version. > UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-3718 > URL: https://issues.jboss.org/browse/WFLY-3718 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: WildFly 8.1.0.Final > Reporter: Gabor Auth > Assignee: Paul Ferraro > Fix For: 8.2.0.Final > > > 2014-07-30 02:12:30,088 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException > at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164) > at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11] > 2014-07-30 02:12:30,786 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /frontend/images/favicon.ico}: java.lang.NullPointerException > at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164) > at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) > at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:711) > at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:137) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11] -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 02:10:40 2014 From: issues at jboss.org (jaikiran pai (JIRA)) Date: Mon, 24 Nov 2014 02:10:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1192) jboss-deployment-structure.xml top level exclusion does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022188#comment-13022188 ] jaikiran pai commented on WFLY-1192: ------------------------------------ Sathiya, follow the guide here https://developer.jboss.org/wiki/HackingOnWildFly. Before choosing an issue to work on, drop a mail to wildfly-dev mailing list https://lists.jboss.org/mailman/listinfo/wildfly-dev (subscribe to that list if you haven't already) and let the developers know you are working on it. > jboss-deployment-structure.xml top level exclusion does not work > ---------------------------------------------------------------- > > Key: WFLY-1192 > URL: https://issues.jboss.org/browse/WFLY-1192 > Project: WildFly > Issue Type: Feature Request > Components: Class Loading > Environment: Windows, RedHat Linux > Reporter: Markus Lindblom > Fix For: Awaiting Volunteers > > > When I try to exclude for example Log4J in the deployment structure I have to exclude it from every subdeployment in the deployment structure file, the top level exclusion should exclude it from the entire EAR and all of its subdeployments. > Ed: The feature request is, to add a convenient way to cause exclusions to cascade to subdeployments. Right now it works per design. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 02:11:40 2014 From: issues at jboss.org (jaikiran pai (JIRA)) Date: Mon, 24 Nov 2014 02:11:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1154) Allow the server to ignore files or groups of files at deployment time In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022189#comment-13022189 ] jaikiran pai commented on WFLY-1154: ------------------------------------ Sathiya, follow the guide here https://developer.jboss.org/wiki/HackingOnWildFly. Before choosing an issue to work on, drop a mail to wildfly-dev mailing list https://lists.jboss.org/mailman/listinfo/wildfly-dev (subscribe to that list if you haven't already) and let the developers know you are working on it. > Allow the server to ignore files or groups of files at deployment time > ---------------------------------------------------------------------- > > Key: WFLY-1154 > URL: https://issues.jboss.org/browse/WFLY-1154 > Project: WildFly > Issue Type: Feature Request > Components: Server > Reporter: Marius Bogoevici > Fix For: Awaiting Volunteers > > > Legacy and migrated applications may occasionally contain files which are incompatible with the Java EE specification and can cause the application to fail the deployment. The difference between those cases and really faulty Java EE applications lies in the intent of the developer - whether they wish for those files to be picked up by the server and processed, or not. > In such cases, it may be useful to expand the deployment specification and to be able to instruct the server to ignore particular files at deployment time. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 03:13:39 2014 From: issues at jboss.org (Jeff Zhang (JIRA)) Date: Mon, 24 Nov 2014 03:13:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2160) Allow Expression for datasource subsystem enabled property In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Zhang resolved WFLY-2160. ------------------------------ Resolution: Done https://github.com/wildfly/wildfly/pull/6976 > Allow Expression for datasource subsystem enabled property > ---------------------------------------------------------- > > Key: WFLY-2160 > URL: https://issues.jboss.org/browse/WFLY-2160 > Project: WildFly > Issue Type: Bug > Components: Domain Management, JCA > Affects Versions: 8.0.0.Alpha4 > Reporter: Steven Rose > Assignee: Jeff Zhang > Priority: Minor > Labels: wildfly > Fix For: 9.0.0.Beta1 > > > Currently the datasource sub system does not allow expressions. I would like to be able to do this: and set the ds1.enabled property via a properties file. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 03:14:39 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Mon, 24 Nov 2014 03:14:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-275) Migrate some RBAC tests from WildFly full to core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Hugonnet updated WFCORE-275: ------------------------------------- Summary: Migrate some RBAC tests from WildFly full to core (was: Migrate soem RBAC test from WildFly full to WFCORE) > Migrate some RBAC tests from WildFly full to core > ------------------------------------------------- > > Key: WFCORE-275 > URL: https://issues.jboss.org/browse/WFCORE-275 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > All RBAC integration testing is currently done in the WILDFLY project whereas the code is in WFCORE. Migrate some tests which are not related to the RBAC usage in WILDFLY to WFCORE. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 03:15:40 2014 From: issues at jboss.org (Jeff Zhang (JIRA)) Date: Mon, 24 Nov 2014 03:15:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1235) rar-info: ResourceAdapterAssociation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBJCA-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Zhang resolved JBJCA-1235. ------------------------------- Resolution: Done https://github.com/ironjacamar/ironjacamar/pull/262 > rar-info: ResourceAdapterAssociation > ------------------------------------ > > Key: JBJCA-1235 > URL: https://issues.jboss.org/browse/JBJCA-1235 > Project: IronJacamar > Issue Type: Task > Components: AS > Reporter: Jesper Pedersen > Assignee: Jeff Zhang > Fix For: 1.2.1.Final > > > The rar-info tool should report the status of javax.resource.spi.ResourceAdapterAssociation for ManagedConnectionFactory and AdminObject > {noformat} > Class: com.acme.eis.MCFImpl > Validating: No > Association: Yes > Sharable: Unknown > ... > Class: com.acme.eis.AOImpl > Association: Yes > Interface: javax.jms.Topic > ... > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 03:19:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 24 Nov 2014 03:19:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBTEST-21) Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTEST-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022212#comment-13022212 ] RH Bugzilla Integration commented on JBTEST-21: ----------------------------------------------- Kabir Khan changed the Status of [bug 1100839|https://bugzilla.redhat.com/show_bug.cgi?id=1100839] from POST to MODIFIED > Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 > -------------------------------------------------------------------- > > Key: JBTEST-21 > URL: https://issues.jboss.org/browse/JBTEST-21 > Project: JBoss Test > Issue Type: Bug > Environment: IBM JDK > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > When test DataSourceOperationsUnitTestCase is build with IBM JDK 1.6 it fails with error : > Tests in error: > org.jboss.as.test.smoke.mgmt.datasource.DataSourceOperationsUnitTestCase: [SHRINKWRAP-93] Cannot use this JDK-based implementation to export as ZIP an archive with no content: 314225ff-6abf-4453-b69b-7dd12b707d65.jar: 0 assets > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 03:23:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 24 Nov 2014 03:23:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-145) CLI run-batch command cannot process files with comments or blank lines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022214#comment-13022214 ] RH Bugzilla Integration commented on WFCORE-145: ------------------------------------------------ Kabir Khan changed the Status of [bug 1148642|https://bugzilla.redhat.com/show_bug.cgi?id=1148642] from POST to MODIFIED > CLI run-batch command cannot process files with comments or blank lines > ----------------------------------------------------------------------- > > Key: WFCORE-145 > URL: https://issues.jboss.org/browse/WFCORE-145 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha8 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > In the JBoss CLI tool, the "run-batch --file=script.cli" command cannot > successfully process lines that start with "#" or blank lines. Comments and > blank lines help readability when creating cli batch scripts. > However, running the batch file containing comments/blank lines as a parameter > to jboss-cli.sh works just fine (./jboss-cli.sh -c --file=script.cli). This > difference in accepted syntax creates some confusion for users who are new to > the CLI tool. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 04:33:39 2014 From: issues at jboss.org (Joe Wertz (JIRA)) Date: Mon, 24 Nov 2014 04:33:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4118) Unable to check result "undefined" in cli In-Reply-To: References: Message-ID: Joe Wertz created WFLY-4118: ------------------------------- Summary: Unable to check result "undefined" in cli Key: WFLY-4118 URL: https://issues.jboss.org/browse/WFLY-4118 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: 9.0.0.Alpha1 Reporter: Joe Wertz Assignee: Joe Wertz Priority: Minor Fix For: 9.0.0.Beta1 if-else constructs in the CLI can't compare against undefined attribute results. Attempt to create any 'if (result == undefined)' algorithms will always return false. The value-comparison can't handle undefined attributes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 04:33:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 24 Nov 2014 04:33:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4118) Unable to check result "undefined" in cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4118: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1158602 > Unable to check result "undefined" in cli > ----------------------------------------- > > Key: WFLY-4118 > URL: https://issues.jboss.org/browse/WFLY-4118 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 9.0.0.Alpha1 > Reporter: Joe Wertz > Assignee: Joe Wertz > Priority: Minor > Fix For: 9.0.0.Beta1 > > > if-else constructs in the CLI can't compare against undefined attribute results. > Attempt to create any 'if (result == undefined)' algorithms will always return false. The value-comparison can't handle undefined attributes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 04:34:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 24 Nov 2014 04:34:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4118) Unable to check result "undefined" in cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022237#comment-13022237 ] RH Bugzilla Integration commented on WFLY-4118: ----------------------------------------------- Joe Wertz changed the Status of [bug 1158602|https://bugzilla.redhat.com/show_bug.cgi?id=1158602] from NEW to ASSIGNED > Unable to check result "undefined" in cli > ----------------------------------------- > > Key: WFLY-4118 > URL: https://issues.jboss.org/browse/WFLY-4118 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 9.0.0.Alpha1 > Reporter: Joe Wertz > Assignee: Joe Wertz > Priority: Minor > Fix For: 9.0.0.Beta1 > > > if-else constructs in the CLI can't compare against undefined attribute results. > Attempt to create any 'if (result == undefined)' algorithms will always return false. The value-comparison can't handle undefined attributes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 05:08:39 2014 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Mon, 24 Nov 2014 05:08:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3548) JTA synchronization for a distributed transaction called with incorrect TCCL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Adamski reassigned WFLY-3548: ------------------------------------ Assignee: Martin Kouba (was: Tomasz Adamski) > JTA synchronization for a distributed transaction called with incorrect TCCL > ---------------------------------------------------------------------------- > > Key: WFLY-3548 > URL: https://issues.jboss.org/browse/WFLY-3548 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.1.0.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > It seems the RequestProcessor which is processing JTA synchronizations > does not have the right TCCL set. > As a result, during synchronization invocation: > * {{NameNotFoundException}} is thrown for a JNDI lookup of "java:comp/UserTransaction" > * if we try to acccess {{org.jboss.weld.Container}} by means of {{org.jboss.as.weld.services.ModuleGroupSingletonProvider.TCCLSingleton}}, we get ISE: "Singleton not set....This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment." -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 05:22:39 2014 From: issues at jboss.org (Jean-Frederic Clere (JIRA)) Date: Mon, 24 Nov 2014 05:22:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBWEB-248) The default error report class valve should be overridable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBWEB-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022264#comment-13022264 ] Jean-Frederic Clere commented on JBWEB-248: ------------------------------------------- Just a system property probably won't do the trick you need to put the valve in a module otherwise you can't load it. > The default error report class valve should be overridable > ---------------------------------------------------------- > > Key: JBWEB-248 > URL: https://issues.jboss.org/browse/JBWEB-248 > Project: JBoss Web > Issue Type: Feature Request > Components: Tomcat > Affects Versions: JBossWeb-7.0.15.GA, JBossWeb-7.0.16.GA > Reporter: Vincent MATHON > Assignee: Remy Maucherat > > The default error report valve class cannot be configured since JBoss 7.x. > The current default implementation (org.apache.catalina.valves.ErrorReportValve) prints the stack trace if any or some server informations. This can be considered as a security issue, so, it would be great to be able to configure a custom error report valve class or at least to be able to filter informations printed by the default one. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 05:35:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 24 Nov 2014 05:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBTEST-21) Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTEST-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022269#comment-13022269 ] RH Bugzilla Integration commented on JBTEST-21: ----------------------------------------------- Carlo de Wolf changed the Status of [bug 1100839|https://bugzilla.redhat.com/show_bug.cgi?id=1100839] from MODIFIED to ASSIGNED > Intermittent fail of DataSourceOperationsUnitTestCase on IBM JDK 1.6 > -------------------------------------------------------------------- > > Key: JBTEST-21 > URL: https://issues.jboss.org/browse/JBTEST-21 > Project: JBoss Test > Issue Type: Bug > Environment: IBM JDK > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > > When test DataSourceOperationsUnitTestCase is build with IBM JDK 1.6 it fails with error : > Tests in error: > org.jboss.as.test.smoke.mgmt.datasource.DataSourceOperationsUnitTestCase: [SHRINKWRAP-93] Cannot use this JDK-based implementation to export as ZIP an archive with no content: 314225ff-6abf-4453-b69b-7dd12b707d65.jar: 0 assets > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 05:52:39 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Mon, 24 Nov 2014 05:52:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4119) Support Slow Consumer Policy In-Reply-To: References: Message-ID: Jeff Mesnil created WFLY-4119: --------------------------------- Summary: Support Slow Consumer Policy Key: WFLY-4119 URL: https://issues.jboss.org/browse/WFLY-4119 Project: WildFly Issue Type: Feature Request Components: JMS Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 9.0.0.Beta1 Support HornetQ Slow consumer policy to KILL or NOTIFY if consumers starts to be to slow consuming messages. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 05:53:39 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Mon, 24 Nov 2014 05:53:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4119) Support Slow Consumer Policy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022273#comment-13022273 ] Jeff Mesnil commented on WFLY-4119: ----------------------------------- HornetQ 2.5.0.Beta1 is required to provide the management integration for the slow consumer policy > Support Slow Consumer Policy > ---------------------------- > > Key: WFLY-4119 > URL: https://issues.jboss.org/browse/WFLY-4119 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > Support HornetQ Slow consumer policy to KILL or NOTIFY if consumers starts to be to slow consuming messages. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 07:30:39 2014 From: issues at jboss.org (Vincent MATHON (JIRA)) Date: Mon, 24 Nov 2014 07:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBWEB-248) The default error report class valve should be overridable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBWEB-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022324#comment-13022324 ] Vincent MATHON commented on JBWEB-248: -------------------------------------- Actually It does work. Anyway it is not portable to wildfly 8.x. I had this need for security reasons that wildfly does anticipate (no stack trace in case of error), so I do not need this hack anymore and this issue may be closed. > The default error report class valve should be overridable > ---------------------------------------------------------- > > Key: JBWEB-248 > URL: https://issues.jboss.org/browse/JBWEB-248 > Project: JBoss Web > Issue Type: Feature Request > Components: Tomcat > Affects Versions: JBossWeb-7.0.15.GA, JBossWeb-7.0.16.GA > Reporter: Vincent MATHON > Assignee: Remy Maucherat > > The default error report valve class cannot be configured since JBoss 7.x. > The current default implementation (org.apache.catalina.valves.ErrorReportValve) prints the stack trace if any or some server informations. This can be considered as a security issue, so, it would be great to be able to configure a custom error report valve class or at least to be able to filter informations printed by the default one. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 07:35:40 2014 From: issues at jboss.org (Rob Stryker (JIRA)) Date: Mon, 24 Nov 2014 07:35:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3152) Failed initializing module org.jboss.as.logging In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022325#comment-13022325 ] Rob Stryker commented on WFLY-3152: ----------------------------------- This bugzilla entry indicates connecting an agent might be a cause: https://bugzilla.redhat.com/show_bug.cgi?id=1037970 It seems JBDS contains plugins that connect an external agent to all new running java processes, scanning for new ones every x-seconds. This may be the cause on our side. The quick connection of the agent will cause this bug. > Failed initializing module org.jboss.as.logging > ------------------------------------------------ > > Key: WFLY-3152 > URL: https://issues.jboss.org/browse/WFLY-3152 > Project: WildFly > Issue Type: Bug > Reporter: Huu Loi Lai > Priority: Blocker > > I try to run integration test with arquillian and wildfly and I get following erros: > ERROR: JBAS014612: Operation ("parallel-extension-add") failed - address: ([]) > java.lang.RuntimeException: JBAS014670: Failed initializing module org.jboss.as.logging > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:99) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:591) > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:469) > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:273) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:268) > at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:314) > at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:294) > at org.jboss.as.server.ServerService.boot(ServerService.java:356) > at org.jboss.as.server.ServerService.boot(ServerService.java:331) > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) > at java.lang.Thread.run(Thread.java:744) > Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager" > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:91) > ... 10 more > Caused by: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager" > at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:103) > at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:98) > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127) > at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:113) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > 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:744) > at org.jboss.threads.JBossThread.run(JBossThread.java:122) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 07:52:39 2014 From: issues at jboss.org (Jean-Frederic Clere (JIRA)) Date: Mon, 24 Nov 2014 07:52:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBWEB-248) The default error report class valve should be overridable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBWEB-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022335#comment-13022335 ] Jean-Frederic Clere commented on JBWEB-248: ------------------------------------------- where do you put the valve? > The default error report class valve should be overridable > ---------------------------------------------------------- > > Key: JBWEB-248 > URL: https://issues.jboss.org/browse/JBWEB-248 > Project: JBoss Web > Issue Type: Feature Request > Components: Tomcat > Affects Versions: JBossWeb-7.0.15.GA, JBossWeb-7.0.16.GA > Reporter: Vincent MATHON > Assignee: Remy Maucherat > > The default error report valve class cannot be configured since JBoss 7.x. > The current default implementation (org.apache.catalina.valves.ErrorReportValve) prints the stack trace if any or some server informations. This can be considered as a security issue, so, it would be great to be able to configure a custom error report valve class or at least to be able to filter informations printed by the default one. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 08:08:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 24 Nov 2014 08:08:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2732) Injected EJB not available to MDB @PreDestroy methods In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022344#comment-13022344 ] RH Bugzilla Integration commented on WFLY-2732: ----------------------------------------------- Jan Martiska changed the Status of [bug 1103786|https://bugzilla.redhat.com/show_bug.cgi?id=1103786] from ON_QA to VERIFIED > Injected EJB not available to MDB @PreDestroy methods > ----------------------------------------------------- > > Key: WFLY-2732 > URL: https://issues.jboss.org/browse/WFLY-2732 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.0.0.CR1 > Reporter: Mustafa Musaji > Assignee: Stuart Douglas > Fix For: 8.0.0.Final > > Attachments: MDBLifeCycleJAR.zip > > > MDB with method annotated with @PreDestroy and injected EJB. In this method we are calling an EJB. When the application is undeployed the PreDestroy method is called but it fails on the call to the injected EJB as it's already been undeployed. > This was fixed in an RFE for Session Beans but does not seem to work for MDB. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 08:22:39 2014 From: issues at jboss.org (Vincent MATHON (JIRA)) Date: Mon, 24 Nov 2014 08:22:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBWEB-248) The default error report class valve should be overridable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBWEB-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022351#comment-13022351 ] Vincent MATHON commented on JBWEB-248: -------------------------------------- In a jar that is stored in JBoss 7 modules. This jar is also the declared as a global module in standalone.xml. > The default error report class valve should be overridable > ---------------------------------------------------------- > > Key: JBWEB-248 > URL: https://issues.jboss.org/browse/JBWEB-248 > Project: JBoss Web > Issue Type: Feature Request > Components: Tomcat > Affects Versions: JBossWeb-7.0.15.GA, JBossWeb-7.0.16.GA > Reporter: Vincent MATHON > Assignee: Remy Maucherat > > The default error report valve class cannot be configured since JBoss 7.x. > The current default implementation (org.apache.catalina.valves.ErrorReportValve) prints the stack trace if any or some server informations. This can be considered as a security issue, so, it would be great to be able to configure a custom error report valve class or at least to be able to filter informations printed by the default one. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 08:30:39 2014 From: issues at jboss.org (Vincent MATHON (JIRA)) Date: Mon, 24 Nov 2014 08:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBWEB-248) The default error report class valve should be overridable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBWEB-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022351#comment-13022351 ] Vincent MATHON edited comment on JBWEB-248 at 11/24/14 8:30 AM: ---------------------------------------------------------------- In a jar that is stored in JBoss 7 modules. This jar is also declared as a global module in standalone.xml. was (Author: vmath): In a jar that is stored in JBoss 7 modules. This jar is also the declared as a global module in standalone.xml. > The default error report class valve should be overridable > ---------------------------------------------------------- > > Key: JBWEB-248 > URL: https://issues.jboss.org/browse/JBWEB-248 > Project: JBoss Web > Issue Type: Feature Request > Components: Tomcat > Affects Versions: JBossWeb-7.0.15.GA, JBossWeb-7.0.16.GA > Reporter: Vincent MATHON > Assignee: Remy Maucherat > > The default error report valve class cannot be configured since JBoss 7.x. > The current default implementation (org.apache.catalina.valves.ErrorReportValve) prints the stack trace if any or some server informations. This can be considered as a security issue, so, it would be great to be able to configure a custom error report valve class or at least to be able to filter informations printed by the default one. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 08:59:39 2014 From: issues at jboss.org (Manfred Otte (JIRA)) Date: Mon, 24 Nov 2014 08:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4120) JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507 In-Reply-To: References: Message-ID: Manfred Otte created WFLY-4120: ---------------------------------- Summary: JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507 Key: WFLY-4120 URL: https://issues.jboss.org/browse/WFLY-4120 Project: WildFly Issue Type: Bug Components: Web Services Affects Versions: 8.2.0.Final Environment: Windows 8.1 Reporter: Manfred Otte Assignee: Alessio Soldano Priority: Minor Regarding JSR 109, chapter 6.3 the "handler chain file can also be packaged and specified in the annotation such that, it is accessible as a resource from the ClassPath. At runtime, container providers must first try to access the handler chain file as per the locations specified in JSR-181 specification. Failing that, they must try to access it as a resource from the ClassPath." The JBoss AS Documentation states that "The war is considered to be a single module, so classes defined in WEB-INF/lib are treated the same as classes in WEB-INF/classes. All classes packaged in the war will be loaded with the same class loader" (https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7). Following this statements I think it should be fine to have a HandlerChain-annnotated Webservice within a JAR inside a WAR (WEB-INF/lib) referencing a handler chain file that ist not part of the JAR but resides in WEB-INF/classes. However this situation results in {code} Internal Server Error { "outcome" => "failed", "failure-description" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"testjsr109.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"testjsr109.war\".PARSE: JBAS018733: Failed to process phase PARSE of deployment \"testjsr109.war\" Caused by: javax.xml.ws.WebServiceException: JBAS015507: Handler chain config file handlerchain.xml not found in ResourceRoot [root=\"/D:/tools/wildfly-8.2.0.Final/bin/content/testjsr109.war/WEB-INF/lib/testjsr109.jar\"]"}}, "rolled-back" => true } {code} The implementation of org.jboss.as.webservices.injection.WSHandlerChainAnnotationProcessor seems to expect, that the handler chain file is always part of the ResourceRoot the annotated WebService lives in. With respect to JSR 109 I think that this expectation is wrong and that a handler chain file outside the JAR is a valid scenario. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 09:05:39 2014 From: issues at jboss.org (Manfred Otte (JIRA)) Date: Mon, 24 Nov 2014 09:05:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4120) JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manfred Otte updated WFLY-4120: ------------------------------- Attachment: testjsr109.war Reproduction should be possible with the attached WAR. It contains a very simple Webservice de.testjsr109.ServiceWithHandlerChain and an even simpler handler both packaged within a JAR. The Webservice is annotated with a relative file-location: @HandlerChain(file = "../../handlerchain.xml"). The handler chain file resides in WEB-INF/classes. Deployment results in above mentioned error. Moving the handler chain file from WEB-INF/classes to the root of the JAR results in a successful deployment and the endpoint is usable. > JAX-WS: HandlerChain-Annotation referencing file outside Java Archive causes JBAS015507 > --------------------------------------------------------------------------------------- > > Key: WFLY-4120 > URL: https://issues.jboss.org/browse/WFLY-4120 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.2.0.Final > Environment: Windows 8.1 > Reporter: Manfred Otte > Assignee: Alessio Soldano > Priority: Minor > Attachments: testjsr109.war > > > Regarding JSR 109, chapter 6.3 the "handler chain file can also be packaged and specified in the annotation such that, it is accessible as a resource from the ClassPath. At runtime, container providers must first try to access the handler chain file as per the locations specified in JSR-181 specification. Failing that, they must try to access it as a resource from the ClassPath." > The JBoss AS Documentation states that "The war is considered to be a single module, so classes defined in WEB-INF/lib are treated the same as classes in WEB-INF/classes. All classes packaged in the war will be loaded with the same class loader" (https://docs.jboss.org/author/display/AS71/Class+Loading+in+AS7). > Following this statements I think it should be fine to have a HandlerChain-annnotated Webservice within a JAR inside a WAR (WEB-INF/lib) referencing a handler chain file that ist not part of the JAR but resides in WEB-INF/classes. However this situation results in > {code} > Internal Server Error > { > "outcome" => "failed", > "failure-description" => {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"testjsr109.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"testjsr109.war\".PARSE: JBAS018733: Failed to process phase PARSE of deployment \"testjsr109.war\" > Caused by: javax.xml.ws.WebServiceException: JBAS015507: Handler chain config file handlerchain.xml not found in ResourceRoot [root=\"/D:/tools/wildfly-8.2.0.Final/bin/content/testjsr109.war/WEB-INF/lib/testjsr109.jar\"]"}}, > "rolled-back" => true > } > {code} > The implementation of org.jboss.as.webservices.injection.WSHandlerChainAnnotationProcessor seems to expect, that the handler chain file is always part of the ResourceRoot the annotated WebService lives in. With respect to JSR 109 I think that this expectation is wrong and that a handler chain file outside the JAR is a valid scenario. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 10:54:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 24 Nov 2014 10:54:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022416#comment-13022416 ] RH Bugzilla Integration commented on JGRP-1898: ----------------------------------------------- Dave Stahl changed the Status of [bug 1159162|https://bugzilla.redhat.com/show_bug.cgi?id=1159162] from NEW to POST > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 11:09:40 2014 From: issues at jboss.org (sathiya seelan (JIRA)) Date: Mon, 24 Nov 2014 11:09:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1192) jboss-deployment-structure.xml top level exclusion does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022426#comment-13022426 ] sathiya seelan commented on WFLY-1192: -------------------------------------- Thanks for your response [~jaikiran] I've followed the "HackinonWildfly" guide and set up locally.But having some issues, like "Testcases are failed". So after fixing those issues, will drop a mail and start working on this issue. > jboss-deployment-structure.xml top level exclusion does not work > ---------------------------------------------------------------- > > Key: WFLY-1192 > URL: https://issues.jboss.org/browse/WFLY-1192 > Project: WildFly > Issue Type: Feature Request > Components: Class Loading > Environment: Windows, RedHat Linux > Reporter: Markus Lindblom > Fix For: Awaiting Volunteers > > > When I try to exclude for example Log4J in the deployment structure I have to exclude it from every subdeployment in the deployment structure file, the top level exclusion should exclude it from the entire EAR and all of its subdeployments. > Ed: The feature request is, to add a convenient way to cause exclusions to cascade to subdeployments. Right now it works per design. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 11:33:40 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 24 Nov 2014 11:33:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-381) DefaultPropertyReplacer can't handle ${:} expression In-Reply-To: References: Message-ID: Brian Stansberry created JBMETA-381: --------------------------------------- Summary: DefaultPropertyReplacer can't handle ${:} expression Key: JBMETA-381 URL: https://issues.jboss.org/browse/JBMETA-381 Project: JBoss Metadata Issue Type: Bug Components: common Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor If the string "${:}" is passed to default property replacer, it does not parse it as indicating File.pathSeparator; rather it treats it as the default delimiter. ${:} resolves to an empty string. a${:} resolves to a ${:}a resolves to a -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 11:43:39 2014 From: issues at jboss.org (Lars Hellgren (JIRA)) Date: Mon, 24 Nov 2014 11:43:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4116) WAR deployment fails on missing security domain dependency In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022437#comment-13022437 ] Lars Hellgren commented on WFLY-4116: ------------------------------------- Jaikiran, Thank you. Lars On Fri, Nov 21, 2014 at 9:23 PM, jaikiran pai (JIRA) > WAR deployment fails on missing security domain dependency > ---------------------------------------------------------- > > Key: WFLY-4116 > URL: https://issues.jboss.org/browse/WFLY-4116 > Project: WildFly > Issue Type: Feature Request > Components: Security, Web (JBoss Web), Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Standalone form-based authentication WAR > Reporter: Lars Hellgren > Assignee: Darran Lofthouse > Fix For: 8.2.0.Final > > > Moving WARs using form based authentication from WildFly 8.1 Final to 8.2 Final fails due to a missing security domain dependency. > *Log* > {noformat} > service jboss.security.security-domain.java:/jaas/haa-portal (missing) dependents: > [service jboss.deployment.unit."haa-security-manager.war".component.SecurityManagerRepositorySessionBean.CREATE, > service jboss.deployment.unit."haa-security-manager.war".component.UserPrefsRepository.CREATE] > {noformat} > *jboss-web.xml* > {code:xml} > > java:/jaas/haa-portal > > {code} > *standalone.xml* > {code:xml} > > > ... > > > > ... > > > > > > {code} > The datasource is deployed and connected. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 12:09:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 24 Nov 2014 12:09:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4116) WAR deployment fails on missing security domain dependency In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFLY-4116. ------------------------------------ Resolution: Rejected > WAR deployment fails on missing security domain dependency > ---------------------------------------------------------- > > Key: WFLY-4116 > URL: https://issues.jboss.org/browse/WFLY-4116 > Project: WildFly > Issue Type: Feature Request > Components: Security, Web (JBoss Web), Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Standalone form-based authentication WAR > Reporter: Lars Hellgren > Assignee: Darran Lofthouse > Fix For: 8.2.0.Final > > > Moving WARs using form based authentication from WildFly 8.1 Final to 8.2 Final fails due to a missing security domain dependency. > *Log* > {noformat} > service jboss.security.security-domain.java:/jaas/haa-portal (missing) dependents: > [service jboss.deployment.unit."haa-security-manager.war".component.SecurityManagerRepositorySessionBean.CREATE, > service jboss.deployment.unit."haa-security-manager.war".component.UserPrefsRepository.CREATE] > {noformat} > *jboss-web.xml* > {code:xml} > > java:/jaas/haa-portal > > {code} > *standalone.xml* > {code:xml} > > > ... > > > > ... > > > > > > {code} > The datasource is deployed and connected. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 13:00:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 24 Nov 2014 13:00:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-276) whoami operation failed when rbac enabled but no roles assigned In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFCORE-276: ------------------------------------ Description: Need to double check this is either the CLI making a call in addition to the whoami op and that call is failing or something being accessed by whoami is causing the failure. Here is the failure for a user with no roles: - {noformat} [standalone at localhost:9990 /] [darranl at localhost bin]$ ./jboss-cli.sh -c --no-local-auth Authenticating against security realm: ManagementRealm Username: UserTwo Password: [standalone at localhost:9990 /] :whoami { "outcome" => "success", "result" => {"identity" => { "username" => "UserTwo", "realm" => "ManagementRealm" }} } [standalone at localhost:9990 /] :whoami(verbose=true) Failed to get the list of the operation properties: "WFLYCTL0313: Unauthorized to execute operation 'read-operation-description' for resource '[]' -- "WFLYCTL0332: Permission denied"" [standalone at localhost:9990 /] {noformat} was:Need to double check this is either the CLI making a call in addition to the whoami op and that call is failing or something being accessed by whoami is causing the failure. > whoami operation failed when rbac enabled but no roles assigned > --------------------------------------------------------------- > > Key: WFCORE-276 > URL: https://issues.jboss.org/browse/WFCORE-276 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > Need to double check this is either the CLI making a call in addition to the whoami op and that call is failing or something being accessed by whoami is causing the failure. > Here is the failure for a user with no roles: - > {noformat} > [standalone at localhost:9990 /] [darranl at localhost bin]$ ./jboss-cli.sh -c --no-local-auth > Authenticating against security realm: ManagementRealm > Username: UserTwo > Password: > [standalone at localhost:9990 /] :whoami > { > "outcome" => "success", > "result" => {"identity" => { > "username" => "UserTwo", > "realm" => "ManagementRealm" > }} > } > [standalone at localhost:9990 /] :whoami(verbose=true) > Failed to get the list of the operation properties: "WFLYCTL0313: Unauthorized to execute operation 'read-operation-description' for resource '[]' -- "WFLYCTL0332: Permission denied"" > [standalone at localhost:9990 /] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 13:55:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 24 Nov 2014 13:55:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022470#comment-13022470 ] RH Bugzilla Integration commented on WFCORE-160: ------------------------------------------------ Jason T. Greene changed the Status of [bug 1145960|https://bugzilla.redhat.com/show_bug.cgi?id=1145960] from POST to MODIFIED > Bash scripts should not attempt to expand argument properties > ------------------------------------------------------------- > > Key: WFCORE-160 > URL: https://issues.jboss.org/browse/WFCORE-160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha10 > > > Scripts that parse the command line arguments use a pattern like > {code} > while [ "$#" -gt 0 ] > do > case "$1" in > *) > CLI_OPTS="$CLI_OPTS \"$1\"" > ;; > esac > shift > done > {code} > The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 13:55:40 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 24 Nov 2014 13:55:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-278) Revisit error message for an authentication failure. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse moved WFLY-3208 to WFCORE-278: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-278 (was: WFLY-3208) Issue Type: Bug (was: Task) Affects Version/s: (was: 8.0.0.Final) Component/s: CLI Domain Management Remoting Security (was: CLI) (was: Domain Management) (was: Remoting) (was: Security) Fix Version/s: 1.0.0.Alpha14 (was: 9.0.0.Beta1) > Revisit error message for an authentication failure. > ---------------------------------------------------- > > Key: WFCORE-278 > URL: https://issues.jboss.org/browse/WFCORE-278 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management, Remoting, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > After authentication fails in the CLI the following error message is output: - > {code} > Unable to authenticate against controller at localhost:9990: Authentication failed: the server presented no authentication mechanisms > {code} > This text is a bit misleading, what it actually means is all mechanisms presented have either been excluded or attempted and now no further mechanisms are available to try. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 13:55:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 24 Nov 2014 13:55:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3285) Domain directory properties only work on specific operating systems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022471#comment-13022471 ] RH Bugzilla Integration commented on WFLY-3285: ----------------------------------------------- Jason T. Greene changed the Status of [bug 1091198|https://bugzilla.redhat.com/show_bug.cgi?id=1091198] from POST to MODIFIED > Domain directory properties only work on specific operating systems > ------------------------------------------------------------------- > > Key: WFLY-3285 > URL: https://issues.jboss.org/browse/WFLY-3285 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.1.0.CR1 > Reporter: Dennis Reed > Assignee: Tomaz Cerar > > domain.sh only parses -Djboss.domain.base.dir, -Djboss.domain.log.dir, and -Djboss.domain.config.dir (used to set -Dlogging.configuration and -Dorg.jboss.boot.log.file) on Linux, Solaris, and OS X. > It does not attempt to parse these (and therefore does not set the logging properties correctly) on any other OS, including AIX. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 13:56:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 24 Nov 2014 13:56:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-279) Upgrade to JBoss Remoting after 4.0.5.Final In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-279: --------------------------------------- Summary: Upgrade to JBoss Remoting after 4.0.5.Final Key: WFCORE-279 URL: https://issues.jboss.org/browse/WFCORE-279 Project: WildFly Core Issue Type: Component Upgrade Components: Remoting Reporter: Darran Lofthouse Assignee: David Lloyd Fix For: 1.0.0.Alpha14 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 14:00:40 2014 From: issues at jboss.org (Emmanuel Hugonnet (JIRA)) Date: Mon, 24 Nov 2014 14:00:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-275) Migrate some RBAC tests from WildFly full to core In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022473#comment-13022473 ] Emmanuel Hugonnet commented on WFCORE-275: ------------------------------------------ AccessConstraintUtilizationTestCase -- non-core ApplicationTypeTestCase -- core -- create a variant using logging StandardRolesBasicTestCase -- core-ish -- replace war, figure out jmx, add extension to replace ds -- CliInterfaceStandardRolesBasicTestCase -- core -- HttpInterfaceStandardRolesBasicTestCase -- core -- NativeInterfaceStandardRolesBasicTestCase -- core -- Jmx2ndInterfaceStandardRolesBasicTestCase ??? -- JmxInterfaceStandardRolesBasicTestCase ??? DeploymentScannerTestCase -- core; replace sar IncludeAllRoleTestCase -- core JmxNonSensitiveTestCase -- with jmx JmxSensitiveTestCase -- with jmx LdapRoleMappingG2UTestCase -- core LdapRoleMappingU2GTestCase -- core PermissionsCoverageTestCase -- core and full ReadResourceDescriptionVsActualOperationTestCase -- core, but meh RejectingCombinationPolicyTestCase -- core RoleMappingRuntimeReconfigurationTestCase -- core RolesIntegrityCheckingTestCase -- core ValidateAddressOrOperationTestCase -- core; replace DS VaultExpressionSensitivityTestCase -- core; replace DS > Migrate some RBAC tests from WildFly full to core > ------------------------------------------------- > > Key: WFCORE-275 > URL: https://issues.jboss.org/browse/WFCORE-275 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > All RBAC integration testing is currently done in the WILDFLY project whereas the code is in WFCORE. Migrate some tests which are not related to the RBAC usage in WILDFLY to WFCORE. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 14:44:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Mon, 24 Nov 2014 14:44:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-276) whoami operation failed when rbac enabled but no roles assigned In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse resolved WFCORE-276. ------------------------------------- Resolution: Won't Fix Marking as 'Won't Fix' as this failure is happening during the validation of a low level command, the recommended approach is to use a high level command. Within the CLI a high level command 'connection-info' already exists which amongst other things outputs the resulting role information from whoami so there is no benefit in adding another high level command to duplicate this. > whoami operation failed when rbac enabled but no roles assigned > --------------------------------------------------------------- > > Key: WFCORE-276 > URL: https://issues.jboss.org/browse/WFCORE-276 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > Need to double check this is either the CLI making a call in addition to the whoami op and that call is failing or something being accessed by whoami is causing the failure. > Here is the failure for a user with no roles: - > {noformat} > [standalone at localhost:9990 /] [darranl at localhost bin]$ ./jboss-cli.sh -c --no-local-auth > Authenticating against security realm: ManagementRealm > Username: UserTwo > Password: > [standalone at localhost:9990 /] :whoami > { > "outcome" => "success", > "result" => {"identity" => { > "username" => "UserTwo", > "realm" => "ManagementRealm" > }} > } > [standalone at localhost:9990 /] :whoami(verbose=true) > Failed to get the list of the operation properties: "WFLYCTL0313: Unauthorized to execute operation 'read-operation-description' for resource '[]' -- "WFLYCTL0332: Permission denied"" > [standalone at localhost:9990 /] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 16:00:40 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 24 Nov 2014 16:00:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-382) Support recursive and nested expressions In-Reply-To: References: Message-ID: Brian Stansberry created JBMETA-382: --------------------------------------- Summary: Support recursive and nested expressions Key: JBMETA-382 URL: https://issues.jboss.org/browse/JBMETA-382 Project: JBoss Metadata Issue Type: Feature Request Components: common Reporter: Brian Stansberry Assignee: Brian Stansberry For management configuration, WildFly and EAP support recursive expression resolution (where if ${x} resolves to ${y}, then ${y] is resolved) and will support nested expression resolution as well. The JBoss Metadata PropertyReplacer stuff should do the same so users get a consistent experience regardless of where they place an expression. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 17:35:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 24 Nov 2014 17:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2795) Escaped expressions are still expanded at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry reassigned WFLY-2795: -------------------------------------- Assignee: Brian Stansberry (was: James Perkins) > Escaped expressions are still expanded at runtime > ------------------------------------------------- > > Key: WFLY-2795 > URL: https://issues.jboss.org/browse/WFLY-2795 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > Priority: Minor > > In DMR expressions can be escaped with {{$$}}. Two passes are made in the [ExpressionResolverImpl|https://github.com/wildfly/wildfly/blob/master/controller/src/main/java/org/jboss/as/controller/ExpressionResolverImpl.java#L119]. The first pass changes {code}$${key}{code} to {code}${key}{code}. The second pass fully expands the expression. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 17:36:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 24 Nov 2014 17:36:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-280) Escaped expressions are still expanded at runtime In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry moved WFLY-2795 to WFCORE-280: ----------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-280 (was: WFLY-2795) Component/s: Domain Management (was: Domain Management) > Escaped expressions are still expanded at runtime > ------------------------------------------------- > > Key: WFCORE-280 > URL: https://issues.jboss.org/browse/WFCORE-280 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > Priority: Minor > > In DMR expressions can be escaped with {{$$}}. Two passes are made in the [ExpressionResolverImpl|https://github.com/wildfly/wildfly/blob/master/controller/src/main/java/org/jboss/as/controller/ExpressionResolverImpl.java#L119]. The first pass changes {code}$${key}{code} to {code}${key}{code}. The second pass fully expands the expression. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 18:34:39 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 24 Nov 2014 18:34:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBMETA-381) DefaultPropertyReplacer can't handle ${:} expression In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBMETA-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022499#comment-13022499 ] Brian Stansberry commented on JBMETA-381: ----------------------------------------- JBMETA-381 and DMR-14 are the same problem in separate codebases. > DefaultPropertyReplacer can't handle ${:} expression > ---------------------------------------------------- > > Key: JBMETA-381 > URL: https://issues.jboss.org/browse/JBMETA-381 > Project: JBoss Metadata > Issue Type: Bug > Components: common > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > If the string "${:}" is passed to default property replacer, it does not parse it as indicating File.pathSeparator; rather it treats it as the default delimiter. > ${:} resolves to an empty string. > a${:} resolves to a > ${:}a resolves to a -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 21:15:41 2014 From: issues at jboss.org (Brian Stansberry (JIRA)) Date: Mon, 24 Nov 2014 21:15:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-280) Recursive resolution breaks expression escaping In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Stansberry updated WFCORE-280: ------------------------------------ Summary: Recursive resolution breaks expression escaping (was: Escaped expressions are still expanded at runtime) > Recursive resolution breaks expression escaping > ----------------------------------------------- > > Key: WFCORE-280 > URL: https://issues.jboss.org/browse/WFCORE-280 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > Priority: Minor > > In DMR expressions can be escaped with {{$$}}. Two passes are made in the [ExpressionResolverImpl|https://github.com/wildfly/wildfly/blob/master/controller/src/main/java/org/jboss/as/controller/ExpressionResolverImpl.java#L119]. The first pass changes {code}$${key}{code} to {code}${key}{code}. The second pass fully expands the expression. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Mon Nov 24 22:12:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Mon, 24 Nov 2014 22:12:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022507#comment-13022507 ] shinzey shinzey commented on WFLY-4096: --------------------------------------- Here's the error message with hibernate.temp.use_jdbc_metadata_defaults set to false: {quote} 11:09:49,484 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "wildweb.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"wildweb.war#wwpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.app.wildweb.wildweb.test]"]) 11:09:49,562 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "wildweb.war" (runtime-name : "wildweb.war") 11:09:49,562 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.naming.context.java.app.wildweb.wildweb.test (missing) dependents: [service jboss.persistenceunit."wildweb.war#wwpu".__FIRST_PHASE__] JBAS014776: Newly corrected services: service jboss.deployment.unit."wildweb.war".beanmanager (no longer required) {quote} An interesting question is since GlassFish can make all of these work together, why can't WildFly? > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4109) Remove outdated policy files from testsuite/integration/src/test/config In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022530#comment-13022530 ] RH Bugzilla Integration commented on WFLY-4109: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1166130|https://bugzilla.redhat.com/show_bug.cgi?id=1166130] from MODIFIED to ON_QA > Remove outdated policy files from testsuite/integration/src/test/config > ----------------------------------------------------------------------- > > Key: WFLY-4109 > URL: https://issues.jboss.org/browse/WFLY-4109 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Minor > > Policy files no-op.policy and permit_all_testsuite.policy are outdated. They should be removed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-99) Infinite recursion when exception stack frame class lookup fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/LOGMGR-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022533#comment-13022533 ] RH Bugzilla Integration commented on LOGMGR-99: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1071695|https://bugzilla.redhat.com/show_bug.cgi?id=1071695] from MODIFIED to ON_QA > Infinite recursion when exception stack frame class lookup fails > ---------------------------------------------------------------- > > Key: LOGMGR-99 > URL: https://issues.jboss.org/browse/LOGMGR-99 > Project: JBoss Log Manager > Issue Type: Bug > Affects Versions: 1.5.1.Final > Reporter: James Livingston > Assignee: James Perkins > Priority: Critical > Fix For: 1.3.3.Final, 1.4.4.Final, 1.5.4.Final, 2.0.0.Beta2 > > Attachments: logmgr99.war > > > To print out the jar information in exception stack traces, the log manager needs to resolve the class name from StackTraceElement to the Class object. Since the log manager cannot know which classloader was used, guessClass() tries the TCCL, the logmanager's classloader and finally the system classloader. > It is possible that the TCCL contains a class of the same name as the one in the stack frame, but it not the same class. This can easily happen if the application packages a jar that is also used by the container. In this situation, the class may not be able to be loaded, such as if the application-packages class is missing it's dependencies. > If Class.forName() would throw a NoClassDefFoundError or similar, JBoss Modules (or other classloader implementation) may attempt to log this using java.util.logging API. This can result in infinite recursion, for example > {code} > ... > at org.jboss.logmanager.Logger.log(Logger.java:367) > at org.jboss.modules.log.JDKModuleLogger.doLog(JDKModuleLogger.java:109) > at org.jboss.modules.log.JDKModuleLogger.classDefineFailed(JDKModuleLogger.java:194) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:401) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:243) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:73) > at org.jboss.modules.Module.loadModuleClass(Module.java:527) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:182) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:266) > at org.jboss.logmanager.formatters.Formatters$12.guessClass(Formatters.java:578) > at org.jboss.logmanager.formatters.Formatters$12.renderExtended(Formatters.java:421) > at org.jboss.logmanager.formatters.Formatters$12.renderRaw(Formatters.java:388) > at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:150) > at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:86) > at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:35) > at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:49) > at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:290) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:298) > at org.jboss.logmanager.Logger.logRaw(Logger.java:721) > at org.jboss.logmanager.Logger.logRaw(Logger.java:731) > at org.jboss.logmanager.Logger.log(Logger.java:367) > ... > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1631) Duplicated message ids in web, undertow, jsf and osgi subsystems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022535#comment-13022535 ] RH Bugzilla Integration commented on WFLY-1631: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 980823|https://bugzilla.redhat.com/show_bug.cgi?id=980823] from MODIFIED to ON_QA > Duplicated message ids in web, undertow, jsf and osgi subsystems > ----------------------------------------------------------------- > > Key: WFLY-1631 > URL: https://issues.jboss.org/browse/WFLY-1631 > Project: WildFly > Issue Type: Bug > Components: JSF, OSGi, Web (Undertow) > Affects Versions: 8.0.0.Alpha2 > Reporter: Ivo Studensky > Assignee: Tomaz Cerar > Priority: Critical > Fix For: 8.0.0.CR1 > > > There is a lot of duplicated or different messages in JBossWeb and Undertow subsystems which has the same ids. > different messages: > {noformat} > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12604, value = "JSF version slot '%s' is missing from module %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12604, value = "WildFlyConversationAwareViewHandler was improperly initialized. Expected ViewHandler parent.") > {noformat} > duplicated messages with the same content: > {noformat} > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12600, value = "Could not load JSF managed bean class: %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12600, value = "Could not load JSF managed bean class: %s") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12601, value = "JSF managed bean class %s has no default constructor") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12601, value = "JSF managed bean class %s has no default constructor") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12602, value = "Failed to parse %s, managed beans defined in this file will not be available") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12602, value = "Failed to parse %s, managed beans defined in this file will not be available") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12603, value = "Unknown JSF version '%s'. Default version '%s' will be used instead.") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12603, value = "Unknown JSF version %s %s will be used instead") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12650, value = "Failed to load annotated class: %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12650, value = "Failed to load annotated class: %s") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12651, value = "Annotation %s in class %s is only allowed on classes") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12651, value = "Annotation %s in class %s is only allowed on classes") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12652, value = "Instance creation failed") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12652, value = "Instance creation failed") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12653, value = "Instance destruction failed") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12653, value = "Instance destruction failed") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12654, value = "Thread local injection container not set") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12654, value = "Thread local injection container not set") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12655, value = "@ManagedBean is only allowed at class level %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12655, value = "@ManagedBean is only allowed at class level %s") > web/src/main/java/org/jboss/as/web/WebMessages.java: @Message(id = 18039, value = "Failed to create context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18039, value = "Failed to create context") > web/src/main/java/org/jboss/as/web/WebMessages.java: @Message(id = 18040, value = "Failed to start context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18040, value = "Failed to start context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18200, value = "Failed to start welcome context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18200, value = "Failed to start welcome context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18201, value = "Failed to destroy welcome context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18201, value = "Failed to destroy welcome context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18202, value = "Error calling onStartup for servlet container initializer: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18202, value = "Error calling onStartup for servlet container initializer: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18203, value = "Error instantiating container component: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18203, value = "Error instantiating container component: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18204, value = "Clustering not supported, falling back to non-clustered session manager") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18204, value = "Clustering not supported, falling back to non-clustered session manager") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18205, value = "Cannot setup overlays for [%s] due to custom resources") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18205, value = "Cannot setup overlays for [%s] due to custom resources") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18206, value = "Webapp [%s] is unavailable due to startup errors") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18206, value = "Webapp [%s] is unavailable due to startup errors") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18208, value = "Failed to start context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18208, value = "Failed to start context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18209, value = "Failed to destroy context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18209, value = "Failed to destroy context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18210, value = "Register web context: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18210, value = "Register web context: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18214, value = "Error during login/password authenticate") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18214, value = "Error during login/password authenticate") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18215, value = "Error during certificate authenticate") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18215, value = "Error during certificate authenticate") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18216, value = "Error during digest authenticate") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18216, value = "Error during digest authenticate") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18217, value = "Error obtaining authorization helper") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18217, value = "Error obtaining authorization helper") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18218, value = "Exception in obtaining server authentication manager") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18218, value = "Exception in obtaining server authentication manager") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18219, value = "JASPI validation for unprotected request context %s failed") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18219, value = "JASPI validation for unprotected request context %s failed") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18220, value = "Caught Exception: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18220, value = "Caught Exception: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18221, value = "Error forwarding to login page: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18221, value = "Error forwarding to login page: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18222, value = "Error forwarding to error page: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18222, value = "Error forwarding to error page: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18224, value = "Unregister web context: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18224, value = "Unregister web context: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18226, value = "Skipped SCI for jar: %s.") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18226, value = "Skipped SCI for jar: %s.") > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-271) The description of the default scanner attribute "scan-enabled" is incorrect. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022536#comment-13022536 ] RH Bugzilla Integration commented on WFCORE-271: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 1162982|https://bugzilla.redhat.com/show_bug.cgi?id=1162982] from MODIFIED to ON_QA > The description of the default scanner attribute "scan-enabled" is incorrect. > ------------------------------------------------------------------------------- > > Key: WFCORE-271 > URL: https://issues.jboss.org/browse/WFCORE-271 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > > Description of problem: The description of the 'scan-enabled' attribute states "Flag indicating that all scanning (including initial scanning at startup) should be disabled." The default value of this attribute is "true", therefore I believe the description is incorrect. > I propose that the description be changed to: "Flag indicating if all scanning (including initial scanning at startup) is enabled." -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:43 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-145) CLI run-batch command cannot process files with comments or blank lines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022537#comment-13022537 ] RH Bugzilla Integration commented on WFCORE-145: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 1148642|https://bugzilla.redhat.com/show_bug.cgi?id=1148642] from MODIFIED to ON_QA > CLI run-batch command cannot process files with comments or blank lines > ----------------------------------------------------------------------- > > Key: WFCORE-145 > URL: https://issues.jboss.org/browse/WFCORE-145 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha8 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > In the JBoss CLI tool, the "run-batch --file=script.cli" command cannot > successfully process lines that start with "#" or blank lines. Comments and > blank lines help readability when creating cli batch scripts. > However, running the batch file containing comments/blank lines as a parameter > to jboss-cli.sh works just fine (./jboss-cli.sh -c --file=script.cli). This > difference in accepted syntax creates some confusion for users who are new to > the CLI tool. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:43 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-451) Filter Apache CXF In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022538#comment-13022538 ] RH Bugzilla Integration commented on WFLY-451: ---------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1166502|https://bugzilla.redhat.com/show_bug.cgi?id=1166502] from MODIFIED to ON_QA > Filter Apache CXF > ----------------- > > Key: WFLY-451 > URL: https://issues.jboss.org/browse/WFLY-451 > Project: WildFly > Issue Type: Task > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 8.0.0.Alpha1 > > > Detect Apache CXF libraries in user deployment and *if* the webservices subsystem is actually being triggered for the deployment, either log a major warning or make the deployment fail. This would basically prevent later issues with users trying to deploy not properly packaged applications (e.g. the same war embedding CXF they were using on Tomcat) and making them aware of what they need to do. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:43 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-187) cli deployment-overlay --redeploy-affected should check subdeployments as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022539#comment-13022539 ] RH Bugzilla Integration commented on WFCORE-187: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 1151435|https://bugzilla.redhat.com/show_bug.cgi?id=1151435] from MODIFIED to ON_QA > cli deployment-overlay --redeploy-affected should check subdeployments as well > ------------------------------------------------------------------------------ > > Key: WFCORE-187 > URL: https://issues.jboss.org/browse/WFCORE-187 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 1.0.0.Alpha11 > > > The redeploy-affected action of the deployment-overlay command checks only the top level deployments, although the changes sent by the command might have actually affected some subdeployments that won't be automatically redeployed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:43 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3999) cli deployment-overlay --redeploy-affected should check subdeployments as well In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022540#comment-13022540 ] RH Bugzilla Integration commented on WFLY-3999: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1151435|https://bugzilla.redhat.com/show_bug.cgi?id=1151435] from MODIFIED to ON_QA > cli deployment-overlay --redeploy-affected should check subdeployments as well > ------------------------------------------------------------------------------ > > Key: WFLY-3999 > URL: https://issues.jboss.org/browse/WFLY-3999 > Project: WildFly > Issue Type: Enhancement > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > Fix For: 9.0.0.Beta1 > > > This issue has to be fixed in wildfly-core but the overlay tests are in the WildFly testsuite. This issue is for the tests covering this issue in WildFly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:44 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-260) Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022545#comment-13022545 ] RH Bugzilla Integration commented on WFCORE-260: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 1161589|https://bugzilla.redhat.com/show_bug.cgi?id=1161589] from MODIFIED to ON_QA > Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab > ------------------------------------------------------------------------------------------ > > Key: WFCORE-260 > URL: https://issues.jboss.org/browse/WFCORE-260 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:45 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-210) IO error during deployment scanning triggers undeployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022547#comment-13022547 ] RH Bugzilla Integration commented on WFCORE-210: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 1159709|https://bugzilla.redhat.com/show_bug.cgi?id=1159709] from MODIFIED to ON_QA > IO error during deployment scanning triggers undeployment > --------------------------------------------------------- > > Key: WFCORE-210 > URL: https://issues.jboss.org/browse/WFCORE-210 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha10 > Reporter: James Livingston > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > If an IO error such as reaching the file descriptor limit occurs during deployment scanning, the scanner continues with an empty deployment list causing it to undeploy applications. > This occurs because FileSystemDeploymentService.scanDirectory() treats File.listFiles() returning null as an empty list rather than an error. http://docs.oracle.com/javase/7/docs/api/java/io/File.html#listFiles%28%29 notes that it returns an empty array if the directory is empty, and null if it is not a directory or an IO error occurs. > It should instead respond to a null return value by aborting the scanner run, with a log message, and not proceed to undeploy applications. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:45 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3969) HeaderTokenParser doesn't parse correctly values which includes a quote In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022548#comment-13022548 ] RH Bugzilla Integration commented on WFLY-3969: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1150024|https://bugzilla.redhat.com/show_bug.cgi?id=1150024] from MODIFIED to ON_QA > HeaderTokenParser doesn't parse correctly values which includes a quote > ----------------------------------------------------------------------- > > Key: WFLY-3969 > URL: https://issues.jboss.org/browse/WFLY-3969 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > Priority: Critical > Fix For: 8.2.0.Final, 9.0.0.Beta1 > > > The header parser doesn't work correctly if a parsed value contains quote character ("). The problem is, the parser is in phase of searching a LAST_QUOTE and it doesn't check if the found quote character is escaped or not. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:45 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022549#comment-13022549 ] RH Bugzilla Integration commented on WFCORE-160: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 1145960|https://bugzilla.redhat.com/show_bug.cgi?id=1145960] from MODIFIED to ON_QA > Bash scripts should not attempt to expand argument properties > ------------------------------------------------------------- > > Key: WFCORE-160 > URL: https://issues.jboss.org/browse/WFCORE-160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha10 > > > Scripts that parse the command line arguments use a pattern like > {code} > while [ "$#" -gt 0 ] > do > case "$1" in > *) > CLI_OPTS="$CLI_OPTS \"$1\"" > ;; > esac > shift > done > {code} > The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:49 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:49 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022556#comment-13022556 ] RH Bugzilla Integration commented on WFCORE-213: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 1018026|https://bugzilla.redhat.com/show_bug.cgi?id=1018026] from MODIFIED to ON_QA > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:28:49 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:28:49 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-269) CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022558#comment-13022558 ] RH Bugzilla Integration commented on WFCORE-269: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 1149099|https://bugzilla.redhat.com/show_bug.cgi?id=1149099] from MODIFIED to ON_QA > CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases > ------------------------------------------------------------------------------- > > Key: WFCORE-269 > URL: https://issues.jboss.org/browse/WFCORE-269 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > This is copy of https://bugzilla.redhat.com/show_bug.cgi?id=1149099 > Description: > The CLI freezes in phase of requesting username/password in some cases. > Reproducer > ========== > Run following command: > ./jboss-cli.sh -c << EOF > /core-service=management/security-realm=ManagementRealm/authentication=local:remove > reload > EOF -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:29:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:29:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-259) Improve realm readiness handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022560#comment-13022560 ] RH Bugzilla Integration commented on WFCORE-259: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 1161668|https://bugzilla.redhat.com/show_bug.cgi?id=1161668] from MODIFIED to ON_QA > Improve realm readiness handling > -------------------------------- > > Key: WFCORE-259 > URL: https://issues.jboss.org/browse/WFCORE-259 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > Currently we display an error message informing users that they need to add a new user if any of the authentication mechanisms within a realm report that they are not ready to handle requests. > The reason for this was so that if properties backed authentication we available along with local authentication then the local authentication would not prevent the prompt from being displayed. > However there could be additional mechanisms suitable for use with HTTP so we need a small modification to stop taking into account the local authentication mechanism but allow requests in if any of the other HTTP compatible mechanisms are ready to handle requests. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:29:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:29:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4110) EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022561#comment-13022561 ] RH Bugzilla Integration commented on WFLY-4110: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1164231|https://bugzilla.redhat.com/show_bug.cgi?id=1164231] from MODIFIED to ON_QA > EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used > --------------------------------------------------------------------------------------- > > Key: WFLY-4110 > URL: https://issues.jboss.org/browse/WFLY-4110 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: Dominik Pospisil > Assignee: Dominik Pospisil > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:29:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:29:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-134) Make sure CLIWrapper doesn't use default encoding In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022562#comment-13022562 ] RH Bugzilla Integration commented on WFCORE-134: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from MODIFIED to ON_QA > Make sure CLIWrapper doesn't use default encoding > ------------------------------------------------- > > Key: WFCORE-134 > URL: https://issues.jboss.org/browse/WFCORE-134 > Project: WildFly Core > Issue Type: Bug > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > CLIWrapper is using the default encoding which might lead to issue with non US locales. > Also take advantage of this fix to remove some hard coded strings from tests. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:29:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:29:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1650) Legacy subsystem testing needs some classloading exclusion mecanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022563#comment-13022563 ] RH Bugzilla Integration commented on WFLY-1650: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from MODIFIED to ON_QA > Legacy subsystem testing needs some classloading exclusion mecanism > ------------------------------------------------------------------- > > Key: WFLY-1650 > URL: https://issues.jboss.org/browse/WFLY-1650 > Project: WildFly > Issue Type: Bug > Components: Logging, Test Suite > Affects Versions: 8.0.0.Alpha3 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Fix For: 8.0.0.Beta1 > > > When translation messages are used (which is the case of EAP) we have conflicts between generated $logger classes when testing submodules. > Some $logger classes exis thus they are loaded by the parent classloader before the childfirstclassloader tries to load them, thus we have a potential ClassCastException brewing. > For exemple this breaks the EAP build on a French OS. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:29:43 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:29:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-245) Add tests for suffix option on size-rotating-file-handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022565#comment-13022565 ] RH Bugzilla Integration commented on WFCORE-245: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 1160541|https://bugzilla.redhat.com/show_bug.cgi?id=1160541] from MODIFIED to ON_QA > Add tests for suffix option on size-rotating-file-handler > --------------------------------------------------------- > > Key: WFCORE-245 > URL: https://issues.jboss.org/browse/WFCORE-245 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: Petr Kremensky > Assignee: James Perkins > > Add tests for WFCORE-113 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:29:43 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:29:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022566#comment-13022566 ] RH Bugzilla Integration commented on WFLY-4054: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1156032|https://bugzilla.redhat.com/show_bug.cgi?id=1156032] from MODIFIED to ON_QA > Unexpected attribute can be added to elements in Transactions Subsystem > ----------------------------------------------------------------------- > > Key: WFLY-4054 > URL: https://issues.jboss.org/browse/WFLY-4054 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. > When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:29:43 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:29:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2806) Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022567#comment-13022567 ] RH Bugzilla Integration commented on WFLY-2806: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1166458|https://bugzilla.redhat.com/show_bug.cgi?id=1166458] from MODIFIED to ON_QA > Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem > ---------------------------------------------------------------------------------------- > > Key: WFLY-2806 > URL: https://issues.jboss.org/browse/WFLY-2806 > Project: WildFly > Issue Type: Feature Request > Components: Web Services > Reporter: Kyle Lape > Assignee: Alessio Soldano > Fix For: 9.0.0.Beta1 > > > If {{CXFServlet}} is defined in an app's {{web.xml}}, the webservices subsystem should always be disabled. (Of course the preference would be to stop using {{CXFServlet}} and follow the JAX-WS way to deploy web services.) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:29:44 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:29:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4089) ServletContainerInitializerDeploymentProcessor does not handle comments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022570#comment-13022570 ] RH Bugzilla Integration commented on WFLY-4089: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1164600|https://bugzilla.redhat.com/show_bug.cgi?id=1164600] from MODIFIED to ON_QA > ServletContainerInitializerDeploymentProcessor does not handle comments > ----------------------------------------------------------------------- > > Key: WFLY-4089 > URL: https://issues.jboss.org/browse/WFLY-4089 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Reporter: James Livingston > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > ServletContainerInitializerDeploymentProcessor.loadSci() has code to read the service file, rather than using the JDK-provided mechanisms, and it does not handle comments. > The API documentation at https://docs.oracle.com/javase/7/docs/api/java/util/ServiceLoader.html says that the # symbols and all following characters on the line should be ignored. It also notes the file must be UTF-8 encoded, and ServletContainerInitializerDeploymentProcessor does not appear to force that either. > Log4j 2.1 triggers this bug (https://issues.apache.org/jira/browse/LOG4J2-890) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:29:45 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:29:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-202) Deadlock when shutdown Wildfly server during CLI client connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022574#comment-13022574 ] RH Bugzilla Integration commented on WFCORE-202: ------------------------------------------------ Vladimir Dosoudil changed the Status of [bug 1151960|https://bugzilla.redhat.com/show_bug.cgi?id=1151960] from MODIFIED to ON_QA > Deadlock when shutdown Wildfly server during CLI client connection > ------------------------------------------------------------------ > > Key: WFCORE-202 > URL: https://issues.jboss.org/browse/WFCORE-202 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha10 > Reporter: Chao Wang > Assignee: Alexey Loubyansky > Fix For: 1.0.0.Alpha13 > > > Creating upstream issue as the same deadlock can be found in WFLY. > Descirption as comment 5 in [BZ1142538|https://bugzilla.redhat.com/show_bug.cgi?id=1142538] > {noformat} > The following deadlock still exists. > Steps to Reproduce: > 1. Prepare a running EAP instance with secured management port - optionally in VM > 2. Execute export JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" > 3. In the same terminal, execute "bin/jboss-cli.sh --connect --controller=$EAP_IP --user=admin --password=password ':read-resource'" > 4. From yet another terminal, execute "jdb -attach localhost:8787" > 5. In JDB: > 5.a. Create breakpoint: "stop in org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 5.b. Resume all threads: "resume" > 5.c. [Execute five times] Wait until breakpoint is hit and execute "resume". Either set timeout or be fast so that timeout does not occur first > 6. Execute "kill -9 $EAP_PID" - optionally in VM > 7. In JDB: > 8.a. Remove breakpoint: "clear org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 8.b. Resume all threads: "resume" > 9. Now dump the stack trace of jboss-cli.sh: "kill -3 $JBOSS_CLI_PID" > Found one Java-level deadlock: > ============================= > "Remoting "cli-client" read-1": > waiting to lock monitor 0x00007ff9c829b558 (object 0x0000000783433408, a java.lang.String), > which is held by "main" > "main": > waiting to lock monitor 0x00007ff9c8333c48 (object 0x00000007851ae6e0, a java.util.ArrayDeque), > which is held by "Remoting "cli-client" read-1" > Java stack information for the threads listed above: > =================================================== > "Remoting "cli-client" read-1": > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:286) > - waiting to lock <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:269) > at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54) > at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:532) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) > at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:392) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:109) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:81) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:183) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.nio.NioHandle.run(NioHandle.java:90) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:198) > "main": > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:361) > - waiting to lock <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.connectionOpened(FutureManagementChannel.java:217) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:78) > - locked <0x0000000784978a00> (a org.jboss.as.protocol.ProtocolConnectionManager) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160) > - locked <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:123) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:98) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:980) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:841) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:817) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:250) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > 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:483) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > {noformat} > It can be easily reproduce with Eclipse as: > {noformat} > 1 start Wildfly > 2 uncomment "JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" in jboss-cli.sh and connect to server > 3 add two break points at > CLIModelControllerClient$ChannelCloseHandler [line: 285] - handleClose(Channel, IOException) > RemoteConnectionChannel [line: 360] - receiveMessage(Receiver) > 4 connect to 8787 from eclipse debug > 5 shutdown Wildfly > A deadlock between "main" and "cli-client" is in Eclipse debug stack. > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:29:45 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:29:45 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3285) Domain directory properties only work on specific operating systems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022575#comment-13022575 ] RH Bugzilla Integration commented on WFLY-3285: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1091198|https://bugzilla.redhat.com/show_bug.cgi?id=1091198] from MODIFIED to ON_QA > Domain directory properties only work on specific operating systems > ------------------------------------------------------------------- > > Key: WFLY-3285 > URL: https://issues.jboss.org/browse/WFLY-3285 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.1.0.CR1 > Reporter: Dennis Reed > Assignee: Tomaz Cerar > > domain.sh only parses -Djboss.domain.base.dir, -Djboss.domain.log.dir, and -Djboss.domain.config.dir (used to set -Dlogging.configuration and -Dorg.jboss.boot.log.file) on Linux, Solaris, and OS X. > It does not attempt to parse these (and therefore does not set the logging properties correctly) on any other OS, including AIX. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:29:46 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:29:46 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4093) Changing IOR settings should require restart of jacorb subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022578#comment-13022578 ] RH Bugzilla Integration commented on WFLY-4093: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1080333|https://bugzilla.redhat.com/show_bug.cgi?id=1080333] from MODIFIED to ON_QA > Changing IOR settings should require restart of jacorb subsystem > ---------------------------------------------------------------- > > Key: WFLY-4093 > URL: https://issues.jboss.org/browse/WFLY-4093 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 9.0.0.Alpha1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: 9.0.0.Beta1 > > > When using management operations to add IOR settings, the settings don't get reflected in the IORSecConfigMetaDataService until a server reload. The management operations should mark that the jacorb subsystem needs to be restarted. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 03:38:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 03:38:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-865) Setting transaction timeout on UserTransaction leaks to the thread and doesn't get cleared In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022586#comment-13022586 ] RH Bugzilla Integration commented on WFLY-865: ---------------------------------------------- Vladimir Dosoudil changed the Status of [bug 900984|https://bugzilla.redhat.com/show_bug.cgi?id=900984] from MODIFIED to ON_QA > Setting transaction timeout on UserTransaction leaks to the thread and doesn't get cleared > ------------------------------------------------------------------------------------------ > > Key: WFLY-865 > URL: https://issues.jboss.org/browse/WFLY-865 > Project: WildFly > Issue Type: Bug > Components: EE, Transactions > Reporter: jaikiran pai > Assignee: David Lloyd > > A user has reported (with an example) that setting a transaction timeout on the UserTransaction will leak the timeout onto the thread and subsequent transaction creation on that thread uses the leaked value instead of new values. > More details in the referenced forum thread. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 04:02:39 2014 From: issues at jboss.org (Josef Cacek (JIRA)) Date: Tue, 25 Nov 2014 04:02:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4121) Wrong LDAP host used in AdvancedLdapLoginModuleTestCase In-Reply-To: References: Message-ID: Josef Cacek created WFLY-4121: --------------------------------- Summary: Wrong LDAP host used in AdvancedLdapLoginModuleTestCase Key: WFLY-4121 URL: https://issues.jboss.org/browse/WFLY-4121 Project: WildFly Issue Type: Bug Reporter: Josef Cacek Assignee: Josef Cacek Priority: Minor An update in {{NetworkUtils.formatPossibleIpv6Address(address)}} method canonizes IPv6 addresses now. The {{AdvancedLdapLoginModuleTestCase}} has to be updated to use correct format for LDAP server SPN in KDC. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 04:26:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 04:26:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JGRP-1878: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1076015, https://bugzilla.redhat.com/show_bug.cgi?id=1167666 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1076015) > Multicast discovery does not work on JDK8 > ----------------------------------------- > > Key: JGRP-1878 > URL: https://issues.jboss.org/browse/JGRP-1878 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.12, 3.5 > Environment: OpenJDK8, OracleJDK8u40 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 3.2.14, 3.6 > > Attachments: mcast.java > > > Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8. > Steps to reproduce with draw, switch to JDK8: > {noformat} > export IP_ADDR=127.0.0.1 > ./draw.sh > export IP_ADDR=192.168.1.10 > ./draw.sh > {noformat} > Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug.. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 04:27:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 04:27:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4121) Wrong LDAP host used in AdvancedLdapLoginModuleTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4121: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1011056 > Wrong LDAP host used in AdvancedLdapLoginModuleTestCase > ------------------------------------------------------- > > Key: WFLY-4121 > URL: https://issues.jboss.org/browse/WFLY-4121 > Project: WildFly > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Minor > > An update in {{NetworkUtils.formatPossibleIpv6Address(address)}} method canonizes IPv6 addresses now. The {{AdvancedLdapLoginModuleTestCase}} has to be updated to use correct format for LDAP server SPN in KDC. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 04:27:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 04:27:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4121) Wrong LDAP host used in AdvancedLdapLoginModuleTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022602#comment-13022602 ] RH Bugzilla Integration commented on WFLY-4121: ----------------------------------------------- Josef Cacek changed the Status of [bug 1011056|https://bugzilla.redhat.com/show_bug.cgi?id=1011056] from ASSIGNED to POST > Wrong LDAP host used in AdvancedLdapLoginModuleTestCase > ------------------------------------------------------- > > Key: WFLY-4121 > URL: https://issues.jboss.org/browse/WFLY-4121 > Project: WildFly > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Minor > > An update in {{NetworkUtils.formatPossibleIpv6Address(address)}} method canonizes IPv6 addresses now. The {{AdvancedLdapLoginModuleTestCase}} has to be updated to use correct format for LDAP server SPN in KDC. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 04:41:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 04:41:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022605#comment-13022605 ] RH Bugzilla Integration commented on JGRP-1878: ----------------------------------------------- Dominik Pospisil changed the Status of [bug 1167666|https://bugzilla.redhat.com/show_bug.cgi?id=1167666] from NEW to ASSIGNED > Multicast discovery does not work on JDK8 > ----------------------------------------- > > Key: JGRP-1878 > URL: https://issues.jboss.org/browse/JGRP-1878 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.12, 3.5 > Environment: OpenJDK8, OracleJDK8u40 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 3.2.14, 3.6 > > Attachments: mcast.java > > > Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8. > Steps to reproduce with draw, switch to JDK8: > {noformat} > export IP_ADDR=127.0.0.1 > ./draw.sh > export IP_ADDR=192.168.1.10 > ./draw.sh > {noformat} > Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug.. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 05:33:40 2014 From: issues at jboss.org (Stefan Stefan (JIRA)) Date: Tue, 25 Nov 2014 05:33:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022637#comment-13022637 ] Stefan Stefan commented on WFLY-825: ------------------------------------ Are there any news on this topic? I've a similar problem with Wildfly 8.0.0.Final on IBM Power i with JDK 7 and JAX-RS Webservices that block on following Stacktrace: {noformat} 3XMTHREADINFO "default task-1" J9VMThread:0x000000018D4C7E00, j9thread_t:0x0000000187F1C890, java/lang/Thread:0x0700000070D206D0, state:B, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0xA5, isDaemon:false) 3XMTHREADINFO1 (native thread ID:0x3DF015, native priority:0x5, native policy:UNKNOWN) 3XMTHREADBLOCK Blocked on: java/util/Collections$UnmodifiableSet at 0x07000000016445B0 Owned by: "default I/O-1" (J9VMThread:0x0000000186EB7F00, java/lang/Thread:0x070000000166BC98) 3XMHEAPALLOC Heap bytes allocated since last GC cycle=1426832 (0x15C590) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at sun/nio/ch/SelectionKeyImpl.nioInterestOps(SelectionKeyImpl.java:133) 4XESTACKTRACE at sun/nio/ch/SelectionKeyImpl.interestOps(SelectionKeyImpl.java:95) 4XESTACKTRACE at org/xnio/nio/WorkerThread.setOps(WorkerThread.java:738) 4XESTACKTRACE at org/xnio/nio/NioHandle.resume(NioHandle.java:42) 4XESTACKTRACE at org/xnio/nio/NioSocketConduit.resumeReads(NioSocketConduit.java:324) 4XESTACKTRACE at org/xnio/conduits/ConduitStreamSourceChannel.resumeReads(ConduitStreamSourceChannel.java:135) 4XESTACKTRACE at io/undertow/server/protocol/http/HttpReadListener.exchangeComplete(HttpReadListener.java:219) 4XESTACKTRACE at io/undertow/server/protocol/http/HttpServerConnection.exchangeComplete(HttpServerConnection.java:218) 4XESTACKTRACE at io/undertow/server/HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1090) 4XESTACKTRACE at io/undertow/server/HttpServerExchange.terminateResponse(HttpServerExchange.java:1310) 4XESTACKTRACE at io/undertow/server/Connectors.terminateResponse(Connectors.java:69) 4XESTACKTRACE at io/undertow/server/protocol/http/ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33) 4XESTACKTRACE at io/undertow/conduits/AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:249) 4XESTACKTRACE at io/undertow/conduits/AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:183) 4XESTACKTRACE at org/xnio/conduits/ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) 4XESTACKTRACE at io/undertow/channels/DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100) 4XESTACKTRACE at org/xnio/channels/Channels.flushBlocking(Channels.java:63) 4XESTACKTRACE at io/undertow/servlet/spec/ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:623) 4XESTACKTRACE at io/undertow/servlet/spec/HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451) 4XESTACKTRACE at io/undertow/servlet/spec/HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525) 4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287) 4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) 4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler.access$000(ServletInitialHandler.java:73) 4XESTACKTRACE at io/undertow/servlet/handlers/ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) 4XESTACKTRACE at io/undertow/server/Connectors.executeRootHandler(Connectors.java:168) 4XESTACKTRACE at io/undertow/server/HttpServerExchange$1.run(HttpServerExchange.java:687) 4XESTACKTRACE at java/util/concurrent/ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121) 4XESTACKTRACE at java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614) 4XESTACKTRACE at java/lang/Thread.run(Thread.java:780) {noformat} > JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance > -------------------------------------------------------- > > Key: WFLY-825 > URL: https://issues.jboss.org/browse/WFLY-825 > Project: WildFly > Issue Type: Bug > Components: Server > Environment: operating system - z/OS version 1.13 > JDK version info: > java version "1.7.0" > Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2)) > IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled) > J9VM - R26_Java726_SR2_20120809_0948_B118929 > JIT - r11.b01_20120808_24925 > GC - R26_Java726_SR2_20120809_0948_B118929 > J9CL - 20120809_118929) > JCL - 20120831_02 based on Oracle 7u3-b05 > Reporter: Bob Bennett > Assignee: Jason Greene > Labels: jboss > Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar > > > When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response: > Hi Bob, > > Have you contacted JBoss support for this issue? > > From my review of the javacore, every application-related thread is > waiting on some kind of internal state monitoring code. The most > prominent cause of waiting appears to be a CountdownLatch used in: > > org/jboss/as/controller/ParallelBootOperationStepHandler > $ParallelBootTransactionControl.operationPrepared > > A quick search found this possibly related JBoss bug which was > introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain > how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t > > The CountdownLatch is one of the Concurrency classes, and is very > simplistic in that it allows an application to direct threads to wait > until some certain number of actions have occured. The application code > (JBoss in this case) would need to explain how many countdowns are > required and which piece of code decrements the counter as needed. > > There's not much to say from a JVM perspective other than the threads > are all waiting for an application-level event (a call to the > "countDown()" method 'N' times where 'N' is how many JBoss initialized > the CountDownLatch to originally.) > > If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread > they think should be executing and why. A system dump of the problem > (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out... > but that won't really be of any use if we don't know what JBoss expects > them to be. > > Regards, > Java Defect Support > Please let me know if you need more info, either from myself or IBM JDK support. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 05:35:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 25 Nov 2014 05:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4122) Unable to build WildFly due to test failure "ModuleNotFoundException: org.jboss.as.webservices.server.integration:main" In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-4122: -------------------------------------- Summary: Unable to build WildFly due to test failure "ModuleNotFoundException: org.jboss.as.webservices.server.integration:main" Key: WFLY-4122 URL: https://issues.jboss.org/browse/WFLY-4122 Project: WildFly Issue Type: Bug Components: Web Services Reporter: Darran Lofthouse Assignee: Alessio Soldano Fix For: 9.0.0.Beta1 Attachments: org.jboss.as.webservices.config.ServerConfigImplTestCase.txt, TEST-org.jboss.as.webservices.config.ServerConfigImplTestCase.xml Currently unable to build WildFly - however this error only seems to affect a couple of users. The build is failing at the following tests: - {noformat} Running org.jboss.as.webservices.config.ServerConfigImplTestCase Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.007 sec <<< FAILURE! - in org.jboss.as.webservices.config.ServerConfigImplTestCase testSingleAttributeUpdate(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0.005 sec <<< ERROR! java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51) at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335) at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64) at org.jboss.as.webservices.config.ServerConfigImplTestCase.internalTestSingleAttributeUpdate(ServerConfigImplTestCase.java:144) at org.jboss.as.webservices.config.ServerConfigImplTestCase.testSingleAttributeUpdate(ServerConfigImplTestCase.java:71) testIsModifiable(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0 sec <<< ERROR! java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51) at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335) at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64) at org.jboss.as.webservices.config.ServerConfigImplTestCase.testIsModifiable(ServerConfigImplTestCase.java:56) testMultipleAttributesUpdate(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0.002 sec <<< ERROR! java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51) at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335) at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64) at org.jboss.as.webservices.config.ServerConfigImplTestCase.internalTestMultipleAttributeUpdate(ServerConfigImplTestCase.java:172) at org.jboss.as.webservices.config.ServerConfigImplTestCase.testMultipleAttributesUpdate(ServerConfigImplTestCase.java:135) Results : Tests in error: ServerConfigImplTestCase.testSingleAttributeUpdate:71->internalTestSingleAttributeUpdate:144 ? Runtime ServerConfigImplTestCase.testIsModifiable:56 ? Runtime org.jboss.modules.Modul... ServerConfigImplTestCase.testMultipleAttributesUpdate:135->internalTestMultipleAttributeUpdate:172 ? Runtime {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 05:35:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Tue, 25 Nov 2014 05:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4122) Unable to build WildFly due to test failure "ModuleNotFoundException: org.jboss.as.webservices.server.integration:main" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darran Lofthouse updated WFLY-4122: ----------------------------------- Attachment: org.jboss.as.webservices.config.ServerConfigImplTestCase.txt TEST-org.jboss.as.webservices.config.ServerConfigImplTestCase.xml > Unable to build WildFly due to test failure "ModuleNotFoundException: org.jboss.as.webservices.server.integration:main" > ----------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4122 > URL: https://issues.jboss.org/browse/WFLY-4122 > Project: WildFly > Issue Type: Bug > Components: Web Services > Reporter: Darran Lofthouse > Assignee: Alessio Soldano > Fix For: 9.0.0.Beta1 > > Attachments: org.jboss.as.webservices.config.ServerConfigImplTestCase.txt, TEST-org.jboss.as.webservices.config.ServerConfigImplTestCase.xml > > > Currently unable to build WildFly - however this error only seems to affect a couple of users. > The build is failing at the following tests: - > {noformat} > Running org.jboss.as.webservices.config.ServerConfigImplTestCase > Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.007 sec <<< FAILURE! - in org.jboss.as.webservices.config.ServerConfigImplTestCase > testSingleAttributeUpdate(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0.005 sec <<< ERROR! > java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51) > at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335) > at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64) > at org.jboss.as.webservices.config.ServerConfigImplTestCase.internalTestSingleAttributeUpdate(ServerConfigImplTestCase.java:144) > at org.jboss.as.webservices.config.ServerConfigImplTestCase.testSingleAttributeUpdate(ServerConfigImplTestCase.java:71) > testIsModifiable(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0 sec <<< ERROR! > java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51) > at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335) > at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64) > at org.jboss.as.webservices.config.ServerConfigImplTestCase.testIsModifiable(ServerConfigImplTestCase.java:56) > testMultipleAttributesUpdate(org.jboss.as.webservices.config.ServerConfigImplTestCase) Time elapsed: 0.002 sec <<< ERROR! > java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.jboss.as.webservices.server.integration:main > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:236) > at org.jboss.as.webservices.util.ModuleClassLoaderProvider.getServerIntegrationClassLoader(ModuleClassLoaderProvider.java:51) > at org.jboss.ws.common.management.AbstractServerConfig.create(AbstractServerConfig.java:335) > at org.jboss.as.webservices.config.ServerConfigImpl.create(ServerConfigImpl.java:64) > at org.jboss.as.webservices.config.ServerConfigImplTestCase.internalTestMultipleAttributeUpdate(ServerConfigImplTestCase.java:172) > at org.jboss.as.webservices.config.ServerConfigImplTestCase.testMultipleAttributesUpdate(ServerConfigImplTestCase.java:135) > Results : > Tests in error: > ServerConfigImplTestCase.testSingleAttributeUpdate:71->internalTestSingleAttributeUpdate:144 ? Runtime > ServerConfigImplTestCase.testIsModifiable:56 ? Runtime org.jboss.modules.Modul... > ServerConfigImplTestCase.testMultipleAttributesUpdate:135->internalTestMultipleAttributeUpdate:172 ? Runtime > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 05:37:39 2014 From: issues at jboss.org (Gabor Auth (JIRA)) Date: Tue, 25 Nov 2014 05:37:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3718) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022640#comment-13022640 ] Gabor Auth commented on WFLY-3718: ---------------------------------- Ok, I've downloaded, installed and the issue is exists, the root cause is same: {code} ==> /home/wildfly/wildfly-8.2.0.Final/domain/servers/server-two/log/server.log <== 2014-11-25 11:31:14,351 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (SessionExpirationScheduler - 1) ISPN000136: Execution error: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.NullPointerException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(org.infinispan.notifications.cachelistener.event.CacheEntryRemovedEvent)] on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager at 294d7185 at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:211) at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22) at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:229) at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:192) at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:230) at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:96) at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:213) at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:92) at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:91) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:275) at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:80) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:132) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:321) at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:402) at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:216) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitRemoveCommand(PessimisticLockingInterceptor.java:145) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:255) at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:196) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:206) at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:156) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:166) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79) at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37) at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57) at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306) at org.infinispan.CacheImpl.removeInternal(CacheImpl.java:407) at org.infinispan.CacheImpl.remove(CacheImpl.java:400) at org.infinispan.DecoratedCache.remove(DecoratedCache.java:406) at org.infinispan.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:281) at org.jboss.as.clustering.infinispan.invoker.Remover$RemoveOperation.invoke(Remover.java:49) at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34) at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:87) at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:117) at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:55) at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:74) at org.wildfly.clustering.web.infinispan.session.ExpiredSessionRemover.remove(ExpiredSessionRemover.java:47) at org.wildfly.clustering.web.infinispan.session.ExpiredSessionRemover.remove(ExpiredSessionRemover.java:32) at org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler$ExpirationTask.run(SessionExpirationScheduler.java:131) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_11] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_11] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_11] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_11] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11] at org.jboss.threads.JBossThread.run(JBossThread.java:122) Caused by: java.lang.NullPointerException at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51) at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:238) at sun.reflect.GeneratedMethodAccessor188.invoke(Unknown Source) [:1.8.0_11] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_11] at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_11] at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:207) ... 80 more {code} > UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-3718 > URL: https://issues.jboss.org/browse/WFLY-3718 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: WildFly 8.1.0.Final > Reporter: Gabor Auth > Assignee: Paul Ferraro > Fix For: 8.2.0.Final > > > 2014-07-30 02:12:30,088 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException > at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164) > at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11] > 2014-07-30 02:12:30,786 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /frontend/images/favicon.ico}: java.lang.NullPointerException > at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164) > at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) > at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:711) > at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:137) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11] -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 06:29:40 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 25 Nov 2014 06:29:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022659#comment-13022659 ] Tomaz Cerar commented on WFLY-825: ---------------------------------- 8.0.0.Final is quite old and has few known problems in undertow / xnio area that ware fixed in later releases. Can you try with 8.2.0.Final that was released last week? > JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance > -------------------------------------------------------- > > Key: WFLY-825 > URL: https://issues.jboss.org/browse/WFLY-825 > Project: WildFly > Issue Type: Bug > Components: Server > Environment: operating system - z/OS version 1.13 > JDK version info: > java version "1.7.0" > Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2)) > IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled) > J9VM - R26_Java726_SR2_20120809_0948_B118929 > JIT - r11.b01_20120808_24925 > GC - R26_Java726_SR2_20120809_0948_B118929 > J9CL - 20120809_118929) > JCL - 20120831_02 based on Oracle 7u3-b05 > Reporter: Bob Bennett > Assignee: Jason Greene > Labels: jboss > Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar > > > When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response: > Hi Bob, > > Have you contacted JBoss support for this issue? > > From my review of the javacore, every application-related thread is > waiting on some kind of internal state monitoring code. The most > prominent cause of waiting appears to be a CountdownLatch used in: > > org/jboss/as/controller/ParallelBootOperationStepHandler > $ParallelBootTransactionControl.operationPrepared > > A quick search found this possibly related JBoss bug which was > introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain > how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t > > The CountdownLatch is one of the Concurrency classes, and is very > simplistic in that it allows an application to direct threads to wait > until some certain number of actions have occured. The application code > (JBoss in this case) would need to explain how many countdowns are > required and which piece of code decrements the counter as needed. > > There's not much to say from a JVM perspective other than the threads > are all waiting for an application-level event (a call to the > "countDown()" method 'N' times where 'N' is how many JBoss initialized > the CountDownLatch to originally.) > > If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread > they think should be executing and why. A system dump of the problem > (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out... > but that won't really be of any use if we don't know what JBoss expects > them to be. > > Regards, > Java Defect Support > Please let me know if you need more info, either from myself or IBM JDK support. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 06:57:39 2014 From: issues at jboss.org (=?UTF-8?Q?Tihomir_Me=C5=A1=C4=8Di=C4=87_=28JIRA=29?=) Date: Tue, 25 Nov 2014 06:57:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode In-Reply-To: References: Message-ID: Tihomir Me??i? created DROOLS-654: ------------------------------------- Summary: Dynamic update with KieContainer.updateToVersion() not working in STREAM mode Key: DROOLS-654 URL: https://issues.jboss.org/browse/DROOLS-654 Project: Drools Issue Type: Bug Affects Versions: 6.2.0.CR2, 6.1.0.Final Environment: Ubuntu Linux Reporter: Tihomir Me??i? Assignee: Mark Proctor Priority: Blocker I'm creating my KieSession by setting STREAM as the event processing mode in the configuration: KieBaseConfiguration config = KieServices.Factory.get() .newKieBaseConfiguration(); config.setOption(EventProcessingOption.STREAM); KieContainer kc = ks.newKieContainer( ... releaseId ... ); KieSession ksession = kc.newKieBase(config).newKieSession(); After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): kc.updateToVersion( ... newReleaseId... ); It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: KieSession ksession = kc.newKieSession(); then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM. When doing a dynamic update using the KieContainer.updateToVersion() -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 06:59:40 2014 From: issues at jboss.org (=?UTF-8?Q?Tihomir_Me=C5=A1=C4=8Di=C4=87_=28JIRA=29?=) Date: Tue, 25 Nov 2014 06:59:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tihomir Me??i? updated DROOLS-654: ---------------------------------- Description: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{ KieBaseConfiguration config = KieServices.Factory.get() .newKieBaseConfiguration(); config.setOption(EventProcessingOption.STREAM); KieContainer kc = ks.newKieContainer( ... releaseId ... ); KieSession ksession = kc.newKieBase(config).newKieSession(); }} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{ kc.updateToVersion( ... newReleaseId... ); }} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{ KieSession ksession = kc.newKieSession(); }} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of). was: I'm creating my KieSession by setting STREAM as the event processing mode in the configuration: KieBaseConfiguration config = KieServices.Factory.get() .newKieBaseConfiguration(); config.setOption(EventProcessingOption.STREAM); KieContainer kc = ks.newKieContainer( ... releaseId ... ); KieSession ksession = kc.newKieBase(config).newKieSession(); After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): kc.updateToVersion( ... newReleaseId... ); It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: KieSession ksession = kc.newKieSession(); then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM. When doing a dynamic update using the KieContainer.updateToVersion() > Dynamic update with KieContainer.updateToVersion() not working in STREAM mode > ----------------------------------------------------------------------------- > > Key: DROOLS-654 > URL: https://issues.jboss.org/browse/DROOLS-654 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: Ubuntu Linux > Reporter: Tihomir Me??i? > Assignee: Mark Proctor > Priority: Blocker > > I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: > {{ > KieBaseConfiguration config = KieServices.Factory.get() > .newKieBaseConfiguration(); > config.setOption(EventProcessingOption.STREAM); > > KieContainer kc = ks.newKieContainer( ... releaseId ... ); > KieSession ksession = kc.newKieBase(config).newKieSession(); > }} > After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): > {{ > kc.updateToVersion( ... newReleaseId... ); > }} > It seems like all of the facts are removed from the session, and my rules are no longer triggered. > When I do not use the configuration object when creating the session and just use: > {{ > KieSession ksession = kc.newKieSession(); > }} > then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 06:59:40 2014 From: issues at jboss.org (=?UTF-8?Q?Tihomir_Me=C5=A1=C4=8Di=C4=87_=28JIRA=29?=) Date: Tue, 25 Nov 2014 06:59:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tihomir Me??i? updated DROOLS-654: ---------------------------------- Description: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{ KieBaseConfiguration config = KieServices.Factory.get() .newKieBaseConfiguration(); config.setOption(EventProcessingOption.STREAM); KieContainer kc = ks.newKieContainer( ... releaseId ... ); KieSession ksession = kc.newKieBase(config).newKieSession();}} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{ kc.updateToVersion( ... newReleaseId... ); }} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{ KieSession ksession = kc.newKieSession(); }} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of). was: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{ KieBaseConfiguration config = KieServices.Factory.get() .newKieBaseConfiguration(); config.setOption(EventProcessingOption.STREAM); KieContainer kc = ks.newKieContainer( ... releaseId ... ); KieSession ksession = kc.newKieBase(config).newKieSession(); }} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{ kc.updateToVersion( ... newReleaseId... ); }} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{ KieSession ksession = kc.newKieSession(); }} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of). > Dynamic update with KieContainer.updateToVersion() not working in STREAM mode > ----------------------------------------------------------------------------- > > Key: DROOLS-654 > URL: https://issues.jboss.org/browse/DROOLS-654 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: Ubuntu Linux > Reporter: Tihomir Me??i? > Assignee: Mark Proctor > Priority: Blocker > > I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: > {{ KieBaseConfiguration config = KieServices.Factory.get() > .newKieBaseConfiguration(); > config.setOption(EventProcessingOption.STREAM); > > KieContainer kc = ks.newKieContainer( ... releaseId ... ); > KieSession ksession = kc.newKieBase(config).newKieSession();}} > After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): > {{ > kc.updateToVersion( ... newReleaseId... ); > }} > It seems like all of the facts are removed from the session, and my rules are no longer triggered. > When I do not use the configuration object when creating the session and just use: > {{ > KieSession ksession = kc.newKieSession(); > }} > then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 07:00:40 2014 From: issues at jboss.org (=?UTF-8?Q?Tihomir_Me=C5=A1=C4=8Di=C4=87_=28JIRA=29?=) Date: Tue, 25 Nov 2014 07:00:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tihomir Me??i? updated DROOLS-654: ---------------------------------- Description: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{KieBaseConfiguration config = KieServices.Factory.get() .newKieBaseConfiguration(); config.setOption(EventProcessingOption.STREAM); KieContainer kc = ks.newKieContainer( ... releaseId ... ); KieSession ksession = kc.newKieBase(config).newKieSession();}} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{ kc.updateToVersion( ... newReleaseId... ); }} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{ KieSession ksession = kc.newKieSession(); }} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of). was: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{ KieBaseConfiguration config = KieServices.Factory.get() .newKieBaseConfiguration(); config.setOption(EventProcessingOption.STREAM); KieContainer kc = ks.newKieContainer( ... releaseId ... ); KieSession ksession = kc.newKieBase(config).newKieSession();}} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{ kc.updateToVersion( ... newReleaseId... ); }} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{ KieSession ksession = kc.newKieSession(); }} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of). > Dynamic update with KieContainer.updateToVersion() not working in STREAM mode > ----------------------------------------------------------------------------- > > Key: DROOLS-654 > URL: https://issues.jboss.org/browse/DROOLS-654 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: Ubuntu Linux > Reporter: Tihomir Me??i? > Assignee: Mark Proctor > Priority: Blocker > > I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: > {{KieBaseConfiguration config = KieServices.Factory.get() > .newKieBaseConfiguration(); > config.setOption(EventProcessingOption.STREAM); > > KieContainer kc = ks.newKieContainer( ... releaseId ... ); > KieSession ksession = kc.newKieBase(config).newKieSession();}} > After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): > {{ > kc.updateToVersion( ... newReleaseId... ); > }} > It seems like all of the facts are removed from the session, and my rules are no longer triggered. > When I do not use the configuration object when creating the session and just use: > {{ > KieSession ksession = kc.newKieSession(); > }} > then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 07:00:40 2014 From: issues at jboss.org (=?UTF-8?Q?Tihomir_Me=C5=A1=C4=8Di=C4=87_=28JIRA=29?=) Date: Tue, 25 Nov 2014 07:00:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tihomir Me??i? updated DROOLS-654: ---------------------------------- Description: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{KieBaseConfiguration config = KieServices.Factory.get()}} {{.newKieBaseConfiguration();}} {{config.setOption(EventProcessingOption.STREAM);}} {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} {{KieSession ksession = kc.newKieBase(config).newKieSession();}} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{kc.updateToVersion( ... newReleaseId... );}} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{KieSession ksession = kc.newKieSession();}} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). was: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{KieBaseConfiguration config = KieServices.Factory.get() .newKieBaseConfiguration(); config.setOption(EventProcessingOption.STREAM); KieContainer kc = ks.newKieContainer( ... releaseId ... ); KieSession ksession = kc.newKieBase(config).newKieSession();}} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{ kc.updateToVersion( ... newReleaseId... ); }} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{ KieSession ksession = kc.newKieSession(); }} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of). > Dynamic update with KieContainer.updateToVersion() not working in STREAM mode > ----------------------------------------------------------------------------- > > Key: DROOLS-654 > URL: https://issues.jboss.org/browse/DROOLS-654 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: Ubuntu Linux > Reporter: Tihomir Me??i? > Assignee: Mark Proctor > Priority: Blocker > > I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: > {{KieBaseConfiguration config = KieServices.Factory.get()}} > {{.newKieBaseConfiguration();}} > {{config.setOption(EventProcessingOption.STREAM);}} > > {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} > {{KieSession ksession = kc.newKieBase(config).newKieSession();}} > After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): > {{kc.updateToVersion( ... newReleaseId... );}} > It seems like all of the facts are removed from the session, and my rules are no longer triggered. > When I do not use the configuration object when creating the session and just use: > {{KieSession ksession = kc.newKieSession();}} > then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 07:01:39 2014 From: issues at jboss.org (=?UTF-8?Q?Tihomir_Me=C5=A1=C4=8Di=C4=87_=28JIRA=29?=) Date: Tue, 25 Nov 2014 07:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tihomir Me??i? updated DROOLS-654: ---------------------------------- Description: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{KieBaseConfiguration config = KieServices.Factory.get()}} {{.newKieBaseConfiguration();}} {{config.setOption(EventProcessingOption.STREAM);}} {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} {{KieSession ksession = kc.newKieBase(config).newKieSession();}} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{kc.updateToVersion( ... newReleaseId... );}} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{KieSession ksession = kc.newKieSession();}} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). was: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{KieBaseConfiguration config = KieServices.Factory.get()}} {{.newKieBaseConfiguration();}} {{config.setOption(EventProcessingOption.STREAM);}} {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} {{KieSession ksession = kc.newKieBase(config).newKieSession();}} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{kc.updateToVersion( ... newReleaseId... );}} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{KieSession ksession = kc.newKieSession();}} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). > Dynamic update with KieContainer.updateToVersion() not working in STREAM mode > ----------------------------------------------------------------------------- > > Key: DROOLS-654 > URL: https://issues.jboss.org/browse/DROOLS-654 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: Ubuntu Linux > Reporter: Tihomir Me??i? > Assignee: Mark Proctor > Priority: Blocker > > I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: > {{KieBaseConfiguration config = KieServices.Factory.get()}} > {{.newKieBaseConfiguration();}} > {{config.setOption(EventProcessingOption.STREAM);}} > > {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} > {{KieSession ksession = kc.newKieBase(config).newKieSession();}} > After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): > {{kc.updateToVersion( ... newReleaseId... );}} > It seems like all of the facts are removed from the session, and my rules are no longer triggered. > When I do not use the configuration object when creating the session and just use: > {{KieSession ksession = kc.newKieSession();}} > then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 07:01:39 2014 From: issues at jboss.org (=?UTF-8?Q?Tihomir_Me=C5=A1=C4=8Di=C4=87_=28JIRA=29?=) Date: Tue, 25 Nov 2014 07:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tihomir Me??i? updated DROOLS-654: ---------------------------------- Description: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{KieBaseConfiguration config = KieServices.Factory.get()}} {{.newKieBaseConfiguration();}} {{config.setOption(EventProcessingOption.STREAM);}} {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} {{KieSession ksession = kc.newKieBase(config).newKieSession();}} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{kc.updateToVersion( ... newReleaseId... );}} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{KieSession ksession = kc.newKieSession();}} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). was: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{KieBaseConfiguration config = KieServices.Factory.get()}} {{.newKieBaseConfiguration();}} {{config.setOption(EventProcessingOption.STREAM);}} {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} {{KieSession ksession = kc.newKieBase(config).newKieSession();}} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{kc.updateToVersion( ... newReleaseId... );}} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{KieSession ksession = kc.newKieSession();}} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). > Dynamic update with KieContainer.updateToVersion() not working in STREAM mode > ----------------------------------------------------------------------------- > > Key: DROOLS-654 > URL: https://issues.jboss.org/browse/DROOLS-654 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: Ubuntu Linux > Reporter: Tihomir Me??i? > Assignee: Mark Proctor > Priority: Blocker > > I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: > {{KieBaseConfiguration config = KieServices.Factory.get()}} > {{.newKieBaseConfiguration();}} > {{config.setOption(EventProcessingOption.STREAM);}} > > {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} > {{KieSession ksession = kc.newKieBase(config).newKieSession();}} > After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): > {{kc.updateToVersion( ... newReleaseId... );}} > It seems like all of the facts are removed from the session, and my rules are no longer triggered. > When I do not use the configuration object when creating the session and just use: > {{KieSession ksession = kc.newKieSession();}} > then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 08:06:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 08:06:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022707#comment-13022707 ] RH Bugzilla Integration commented on WFCORE-242: ------------------------------------------------ Tomas Hofman changed the Status of [bug 1162444|https://bugzilla.redhat.com/show_bug.cgi?id=1162444] from NEW to ASSIGNED > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 08:15:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 08:15:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1149) Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022714#comment-13022714 ] RH Bugzilla Integration commented on WFLY-1149: ----------------------------------------------- Jan Martiska changed the Status of [bug 923836|https://bugzilla.redhat.com/show_bug.cgi?id=923836] from ON_QA to VERIFIED > Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open. > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1149 > URL: https://issues.jboss.org/browse/WFLY-1149 > Project: WildFly > Issue Type: Bug > Components: Naming, Test Suite > Environment: IBM JDK 6 (build 20110203_074623) > IBM JDK 7 (build 20120809_118929) > Reporter: Ivo Studensky > Assignee: Jason Greene > Attachments: endpoint_is_not_open_2012-11-26.xml, failed_with_status_cancelled_2012-11-26.xml, test_output_with_trace_logging_in_EndpointCache.xml > > > RemoteNamingTestCase intermittently fails when running on IBM JDK. According to logs the remoting channel had been closed before the endpoint tried to connect to it. Unfortunately, when I was trying to debug this issue the tests always nicely passed. > test.log snippet: > {noformat} > 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" read-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" read-1', selector sun.nio.ch.EPollSelectorImpl at 345642e1 > 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" write-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" write-1', selector sun.nio.ch.EPollSelectorImpl at 1dc68cf2 > 13:16:31,121 DEBUG [org.jboss.naming.remote.client.InitialContextFactory] (main) jboss.naming.client.connect.options. has the following options {org.xnio.Options.SASL_POLICY_NOPLAINTEXT=>false} > 13:16:31,191 ERROR [org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1] (Remoting "config-based-naming-client-endpoint" task-1) Channel end notification received, closing channel Channel ID d1f17196 (outbound) of Remoting connection fd3dcedc to /127.0.0.1:4447 > 13:16:31,204 DEBUG [org.jboss.naming.remote.client.HaRemoteNamingStore] (main) Failed to connect to server remote://127.0.0.1:4447: org.jboss.remoting3.NotOpenException: Endpoint is not open > at org.jboss.remoting3.EndpointImpl.resourceUntick(EndpointImpl.java:182) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:261) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333) > at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105) > at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:179) > at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:117) > at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79) > at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83) > at javax.naming.InitialContext.lookup(InitialContext.java:422) > at org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase.testRemoteLookup(RemoteNamingTestCase.java:74) > {noformat} > server.log snippet: > {noformat} > 13:16:31,025 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "test.jar" > 13:16:31,163 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-3) Channel Opened - Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 > 13:16:31,176 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-4) Chosen version 0x01 > 13:16:31,189 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" read-1) Channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 closed. > 13:16:31,193 INFO [org.jboss.as.naming] (Remoting "thinkpax" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to null > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 08:21:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 08:21:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022718#comment-13022718 ] RH Bugzilla Integration commented on JGRP-1898: ----------------------------------------------- Sebastian ?askawiec changed the Status of [bug 1159162|https://bugzilla.redhat.com/show_bug.cgi?id=1159162] from POST to MODIFIED > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 08:23:40 2014 From: issues at jboss.org (Stefan Erichsen (JIRA)) Date: Tue, 25 Nov 2014 08:23:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022721#comment-13022721 ] Stefan Erichsen commented on WFLY-825: -------------------------------------- Hi Tomar, thanks for your quick response. Unfortunately WildFly 8.1.0.Final and 8.2.0.Final won't even start on the machine. {code:java} ========================================================================= JBoss Bootstrap Environment JBOSS_HOME: /wildfly-8.2.0.Final JAVA: /QOpenSys/QIBM/ProdData/JavaVM/jdk70/64bit/bin/java JAVA_OPTS: -Xms64m -Xmx2048m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.bytema n -Djava.awt.headless=true -Xdebug -Xrunjdwp:transport=dt_socket,address=5051,server=y,suspend=n ========================================================================= Listening for transport dt_socket at address: 5051 [0m14:16:54,330 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final [0m [0m14:16:55,150 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final [0m [0m14:16:55,251 INFO [org.jboss.as] (MSC service thread 1-8) JBAS015899: WildFly 8.2.0.Final "Tweek" starting [0m [0m14:16:58,363 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http) [0m [0m14:16:58,392 INFO [org.xnio] (MSC service thread 1-4) XNIO version 3.3.0.Final [0m [0m14:16:58,412 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.3.0.Final [0mUnhandled exception Type=Illegal instruction vmState=0x00040000 J9Generic_Signal_Number=00000010 Signal_Number=00000004 Error_Value=00000000 Signal_Code=00000009 Handler1=09001000A0248020 Handler2=09001000A023F518 R0=F9A052647CFFF7E0 R1=00000001832E5CF0 R2=00000000000002E6 R3=FFFFFFFFFFFFFFFF R4=FFFFFFFFFFFFFFFF R5=0000000000002000 R6=00000001859B51E0 R7=0000000000000003 R8=000000018499BED4 R9=09001000A02798E8 R10=000000018499BED4 R11=0000000000003610 R12=0000000000000102 R13=00000001832EF800 R14=00000001859B51B0 R15=00000001832F3F00 R16=0000000000000007 R17=0000000000000000 R18=09001000A024C6D0 R19=09001000A0453020 R20=0000000185B0F250 R21=00000001859B51E0 R22=00000001832F3FF0 R23=0000000000000000 R24=000000000000007E R25=09001000A0241DD0 R26=000000000000007E R27=00000001832E7680 R28=0000000000000002 R29=09001000A0248020 R30=00000001832E6440 R31=0000000000040000 IAR=0000000000003618 LR=090000000282E4D8 MSR=800000000000F032 CTR=0000000000003610 CR=8200004B32000001 FPSCR=8200000000000000 XER=3200000182000000 FPR0 0000000082000000 (f: 2181038080,000000, d: 1,077576e-314) FPR1 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR2 41e8630000000000 (f: 0,000000, d: 3,273130e+09) FPR3 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR4 41d3729e61400000 (f: 1631584256,000000, d: 1,305115e+09) FPR5 4323575afd29b546 (f: 4247368960,000000, d: 2,722036e+15) FPR6 00000000000a74c0 (f: 685248,000000, d: 3,385575e-318) FPR7 4124e98000000000 (f: 0,000000, d: 6,852480e+05) FPR8 000000005474814a (f: 1416921472,000000, d: 7,000522e-315) FPR9 41d51d2052800000 (f: 1384120320,000000, d: 1,416921e+09) FPR10 43128bfb13208000 (f: 320897024,000000, d: 1,305115e+15) FPR11 000000004dca7985 (f: 1305115008,000000, d: 6,448125e-315) FPR12 40b0000000000000 (f: 0,000000, d: 4,096000e+03) FPR13 4020800000000000 (f: 0,000000, d: 8,250000e+00) FPR14 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR15 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR16 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR17 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR18 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR19 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR20 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR21 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR22 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR23 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR24 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR25 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR26 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR27 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR28 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR29 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR30 0000000000000000 (f: 0,000000, d: 0,000000e+00) FPR31 0000000000000000 (f: 0,000000, d: 0,000000e+00) Target=2_60_20121024_126071 (OS/400 V7R1M0) CPU=ppc64 (4 logical CPUs) (0x4c0000000 RAM) ----------- Stack Backtrace ----------- .VMprJavaSendNative (0x09000000008153D4 [libj9vm26.so+0x933d4]) .java_lang_J9VMInternals_initializeImpl (0x09000000025BC924 [libjclse7b_26.so+0x1d924]) .java_lang_J9VMInternals_newInstanceImpl (0x09000000025BC430 [libjclse7b_26.so+0x1d430]) javaProtectedThreadProc+0x13c (0x0900000000788BC0 [libj9vm26.so+0x6bc0]) j9sig_protect+0x38c (0x090000000091CF30 [libj9prt26.so+0x2f30]) javaThreadProc+0x70 (0x09000000007889F4 [libj9vm26.so+0x69f4]) thread_wrapper+0x14c (0x09000000008ED410 [libj9thr26.so+0x3410]) _pthread_body+0x100 (0x09000000003CAD64 [libpthreads.a+0x3d64]) --------------------------------------- JVMDUMP039I JVMDUMP032I JVM forderte als Antwort auf ein Ereignis einen Speicherauszug von System mit "/core.20141125.141658.80445.0001.dmp" an JVMDUMP010I Speicherauszug von System in /core.20141125.141658.80445.0001.dmp geschrieben JVMDUMP032I JVM forderte als Antwort auf ein Ereignis einen Speicherauszug von Java mit "/javacore.20141125.141658.80445.0002.txt" an JVMDUMP010I Speicherauszug von Java in /javacore.20141125.141658.80445.0002.txt geschrieben JVMDUMP032I JVM forderte als Antwort auf ein Ereignis einen Speicherauszug von Snap mit "/Snap.20141125.141658.80445.0003.trc" an JVMDUMP010I Speicherauszug von Snap in /Snap.20141125.141658.80445.0003.trc geschrieben JVMDUMP013I Speicherauszugsereignis "gpf", Detail "" wurde verarbeitet. {code} > JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance > -------------------------------------------------------- > > Key: WFLY-825 > URL: https://issues.jboss.org/browse/WFLY-825 > Project: WildFly > Issue Type: Bug > Components: Server > Environment: operating system - z/OS version 1.13 > JDK version info: > java version "1.7.0" > Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2)) > IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled) > J9VM - R26_Java726_SR2_20120809_0948_B118929 > JIT - r11.b01_20120808_24925 > GC - R26_Java726_SR2_20120809_0948_B118929 > J9CL - 20120809_118929) > JCL - 20120831_02 based on Oracle 7u3-b05 > Reporter: Bob Bennett > Assignee: Jason Greene > Labels: jboss > Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar > > > When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response: > Hi Bob, > > Have you contacted JBoss support for this issue? > > From my review of the javacore, every application-related thread is > waiting on some kind of internal state monitoring code. The most > prominent cause of waiting appears to be a CountdownLatch used in: > > org/jboss/as/controller/ParallelBootOperationStepHandler > $ParallelBootTransactionControl.operationPrepared > > A quick search found this possibly related JBoss bug which was > introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain > how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t > > The CountdownLatch is one of the Concurrency classes, and is very > simplistic in that it allows an application to direct threads to wait > until some certain number of actions have occured. The application code > (JBoss in this case) would need to explain how many countdowns are > required and which piece of code decrements the counter as needed. > > There's not much to say from a JVM perspective other than the threads > are all waiting for an application-level event (a call to the > "countDown()" method 'N' times where 'N' is how many JBoss initialized > the CountDownLatch to originally.) > > If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread > they think should be executing and why. A system dump of the problem > (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out... > but that won't really be of any use if we don't know what JBoss expects > them to be. > > Regards, > Java Defect Support > Please let me know if you need more info, either from myself or IBM JDK support. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 08:50:40 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Tue, 25 Nov 2014 08:50:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022740#comment-13022740 ] Tomaz Cerar commented on WFLY-825: ---------------------------------- Can you try without remote debugging enabled as this could cause some problems. in short just remove "-Xdebug -Xrunjdwp:transport=dt_socket,address=5051,server=y,suspend=n" properties. if it is still a problem can you attach also javacore dump. > JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance > -------------------------------------------------------- > > Key: WFLY-825 > URL: https://issues.jboss.org/browse/WFLY-825 > Project: WildFly > Issue Type: Bug > Components: Server > Environment: operating system - z/OS version 1.13 > JDK version info: > java version "1.7.0" > Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2)) > IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled) > J9VM - R26_Java726_SR2_20120809_0948_B118929 > JIT - r11.b01_20120808_24925 > GC - R26_Java726_SR2_20120809_0948_B118929 > J9CL - 20120809_118929) > JCL - 20120831_02 based on Oracle 7u3-b05 > Reporter: Bob Bennett > Assignee: Jason Greene > Labels: jboss > Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar > > > When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response: > Hi Bob, > > Have you contacted JBoss support for this issue? > > From my review of the javacore, every application-related thread is > waiting on some kind of internal state monitoring code. The most > prominent cause of waiting appears to be a CountdownLatch used in: > > org/jboss/as/controller/ParallelBootOperationStepHandler > $ParallelBootTransactionControl.operationPrepared > > A quick search found this possibly related JBoss bug which was > introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain > how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t > > The CountdownLatch is one of the Concurrency classes, and is very > simplistic in that it allows an application to direct threads to wait > until some certain number of actions have occured. The application code > (JBoss in this case) would need to explain how many countdowns are > required and which piece of code decrements the counter as needed. > > There's not much to say from a JVM perspective other than the threads > are all waiting for an application-level event (a call to the > "countDown()" method 'N' times where 'N' is how many JBoss initialized > the CountDownLatch to originally.) > > If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread > they think should be executing and why. A system dump of the problem > (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out... > but that won't really be of any use if we don't know what JBoss expects > them to be. > > Regards, > Java Defect Support > Please let me know if you need more info, either from myself or IBM JDK support. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 08:54:41 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 25 Nov 2014 08:54:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022743#comment-13022743 ] David Lloyd commented on WFLY-825: ---------------------------------- Regarding my (much) earlier comment about {{-Dxnio.nio.old-locking}}, you have to define it to be "true" in order for it to actually take effect. Like this: {{-Dxnio.nio.old-locking=true}} Also, I don't know much about z/OS but is there a way you could attach the {{/javacore.20141125.141658.80445.0002.txt}} file? > JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance > -------------------------------------------------------- > > Key: WFLY-825 > URL: https://issues.jboss.org/browse/WFLY-825 > Project: WildFly > Issue Type: Bug > Components: Server > Environment: operating system - z/OS version 1.13 > JDK version info: > java version "1.7.0" > Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2)) > IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled) > J9VM - R26_Java726_SR2_20120809_0948_B118929 > JIT - r11.b01_20120808_24925 > GC - R26_Java726_SR2_20120809_0948_B118929 > J9CL - 20120809_118929) > JCL - 20120831_02 based on Oracle 7u3-b05 > Reporter: Bob Bennett > Assignee: Jason Greene > Labels: jboss > Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar > > > When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response: > Hi Bob, > > Have you contacted JBoss support for this issue? > > From my review of the javacore, every application-related thread is > waiting on some kind of internal state monitoring code. The most > prominent cause of waiting appears to be a CountdownLatch used in: > > org/jboss/as/controller/ParallelBootOperationStepHandler > $ParallelBootTransactionControl.operationPrepared > > A quick search found this possibly related JBoss bug which was > introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain > how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t > > The CountdownLatch is one of the Concurrency classes, and is very > simplistic in that it allows an application to direct threads to wait > until some certain number of actions have occured. The application code > (JBoss in this case) would need to explain how many countdowns are > required and which piece of code decrements the counter as needed. > > There's not much to say from a JVM perspective other than the threads > are all waiting for an application-level event (a call to the > "countDown()" method 'N' times where 'N' is how many JBoss initialized > the CountDownLatch to originally.) > > If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread > they think should be executing and why. A system dump of the problem > (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out... > but that won't really be of any use if we don't know what JBoss expects > them to be. > > Regards, > Java Defect Support > Please let me know if you need more info, either from myself or IBM JDK support. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 09:03:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 09:03:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022746#comment-13022746 ] RH Bugzilla Integration commented on JGRP-1878: ----------------------------------------------- Dominik Pospisil changed the Status of [bug 1167666|https://bugzilla.redhat.com/show_bug.cgi?id=1167666] from ASSIGNED to POST > Multicast discovery does not work on JDK8 > ----------------------------------------- > > Key: JGRP-1878 > URL: https://issues.jboss.org/browse/JGRP-1878 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.12, 3.5 > Environment: OpenJDK8, OracleJDK8u40 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 3.2.14, 3.6 > > Attachments: mcast.java > > > Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8. > Steps to reproduce with draw, switch to JDK8: > {noformat} > export IP_ADDR=127.0.0.1 > ./draw.sh > export IP_ADDR=192.168.1.10 > ./draw.sh > {noformat} > Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug.. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 09:17:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 09:17:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022754#comment-13022754 ] RH Bugzilla Integration commented on WFCORE-242: ------------------------------------------------ Brian Stansberry changed the Status of [bug 1162444|https://bugzilla.redhat.com/show_bug.cgi?id=1162444] from ASSIGNED to POST > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 09:27:39 2014 From: issues at jboss.org (Heiko Braun (JIRA)) Date: Tue, 25 Nov 2014 09:27:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4123) Provide a top-level 'map' operation to execute domain wide queries on the server side In-Reply-To: References: Message-ID: Heiko Braun created WFLY-4123: --------------------------------- Summary: Provide a top-level 'map' operation to execute domain wide queries on the server side Key: WFLY-4123 URL: https://issues.jboss.org/browse/WFLY-4123 Project: WildFly Issue Type: Feature Request Reporter: Heiko Braun Assignee: Jason Greene Fix For: 9.0.0.Beta1 See https://github.com/hpehl/map-reduce -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 09:27:39 2014 From: issues at jboss.org (Heiko Braun (JIRA)) Date: Tue, 25 Nov 2014 09:27:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4123) Provide a top-level 'map' operation to execute domain wide queries on the server side In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heiko Braun reassigned WFLY-4123: --------------------------------- Assignee: Heiko Braun (was: Jason Greene) > Provide a top-level 'map' operation to execute domain wide queries on the server side > ------------------------------------------------------------------------------------- > > Key: WFLY-4123 > URL: https://issues.jboss.org/browse/WFLY-4123 > Project: WildFly > Issue Type: Feature Request > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 9.0.0.Beta1 > > > See https://github.com/hpehl/map-reduce -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 09:36:40 2014 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Tue, 25 Nov 2014 09:36:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4124) upgrade to websocket-api_1.1_spec In-Reply-To: References: Message-ID: Scott Marlow created WFLY-4124: ---------------------------------- Summary: upgrade to websocket-api_1.1_spec Key: WFLY-4124 URL: https://issues.jboss.org/browse/WFLY-4124 Project: WildFly Issue Type: Task Components: Web Sockets Reporter: Scott Marlow Assignee: Scott Marlow Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 09:52:40 2014 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Tue, 25 Nov 2014 09:52:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022787#comment-13022787 ] Scott Marlow commented on WFLY-4096: ------------------------------------ [~shinzey] is that the entire exception call stack? Was there another deployment error also shown? Regarding WFLY-2727 "@DataSourceDefinition defined data source can't be used in persistence.xml with CDI entity listeners", can you show a more complete example or a test case. Even better, would be if you look at the simple [https://github.com/wildfly/wildfly/tree/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/datasourcedefinition] test case and suggest what would be required to reproduce the failure. > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 10:10:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 10:10:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4121) Wrong LDAP host used in AdvancedLdapLoginModuleTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022794#comment-13022794 ] RH Bugzilla Integration commented on WFLY-4121: ----------------------------------------------- Kabir Khan changed the Status of [bug 1011056|https://bugzilla.redhat.com/show_bug.cgi?id=1011056] from POST to MODIFIED > Wrong LDAP host used in AdvancedLdapLoginModuleTestCase > ------------------------------------------------------- > > Key: WFLY-4121 > URL: https://issues.jboss.org/browse/WFLY-4121 > Project: WildFly > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Minor > > An update in {{NetworkUtils.formatPossibleIpv6Address(address)}} method canonizes IPv6 addresses now. The {{AdvancedLdapLoginModuleTestCase}} has to be updated to use correct format for LDAP server SPN in KDC. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 10:27:40 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Tue, 25 Nov 2014 10:27:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1470) Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene resolved WFLY-1470. -------------------------------- Resolution: Done Guards have been added in the known problematic places. > Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) > ------------------------------------------------------------------------------------------------- > > Key: WFLY-1470 > URL: https://issues.jboss.org/browse/WFLY-1470 > Project: WildFly > Issue Type: Task > Reporter: Carlo de Wolf > Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 10:27:41 2014 From: issues at jboss.org (Jason Greene (JIRA)) Date: Tue, 25 Nov 2014 10:27:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1470) Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Greene reassigned WFLY-1470: ---------------------------------- Assignee: Jason Greene > Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) > ------------------------------------------------------------------------------------------------- > > Key: WFLY-1470 > URL: https://issues.jboss.org/browse/WFLY-1470 > Project: WildFly > Issue Type: Task > Reporter: Carlo de Wolf > Assignee: Jason Greene > Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 10:29:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 10:29:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1470) Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022810#comment-13022810 ] RH Bugzilla Integration commented on WFLY-1470: ----------------------------------------------- Jason T. Greene changed the Status of [bug 901231|https://bugzilla.redhat.com/show_bug.cgi?id=901231] from NEW to MODIFIED > Usage of finalize() needs extra guards due to a flaw in the language feature (mostly affects IBM) > ------------------------------------------------------------------------------------------------- > > Key: WFLY-1470 > URL: https://issues.jboss.org/browse/WFLY-1470 > Project: WildFly > Issue Type: Task > Reporter: Carlo de Wolf > Assignee: Jason Greene > Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 10:32:39 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Tue, 25 Nov 2014 10:32:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3794) Upgrade HornetQ to 2.5.0.Beta1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil updated WFLY-3794: ------------------------------ Summary: Upgrade HornetQ to 2.5.0.Beta1 (was: Upgrade HornetQ to 2.5.0.ALPHA) > Upgrade HornetQ to 2.5.0.Beta1 > ------------------------------ > > Key: WFLY-3794 > URL: https://issues.jboss.org/browse/WFLY-3794 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 10:37:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 10:37:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-202) Deadlock when shutdown Wildfly server during CLI client connection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022815#comment-13022815 ] RH Bugzilla Integration commented on WFCORE-202: ------------------------------------------------ Hynek Mlnarik changed the Status of [bug 1151960|https://bugzilla.redhat.com/show_bug.cgi?id=1151960] from ON_QA to VERIFIED > Deadlock when shutdown Wildfly server during CLI client connection > ------------------------------------------------------------------ > > Key: WFCORE-202 > URL: https://issues.jboss.org/browse/WFCORE-202 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha10 > Reporter: Chao Wang > Assignee: Alexey Loubyansky > Fix For: 1.0.0.Alpha13 > > > Creating upstream issue as the same deadlock can be found in WFLY. > Descirption as comment 5 in [BZ1142538|https://bugzilla.redhat.com/show_bug.cgi?id=1142538] > {noformat} > The following deadlock still exists. > Steps to Reproduce: > 1. Prepare a running EAP instance with secured management port - optionally in VM > 2. Execute export JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" > 3. In the same terminal, execute "bin/jboss-cli.sh --connect --controller=$EAP_IP --user=admin --password=password ':read-resource'" > 4. From yet another terminal, execute "jdb -attach localhost:8787" > 5. In JDB: > 5.a. Create breakpoint: "stop in org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 5.b. Resume all threads: "resume" > 5.c. [Execute five times] Wait until breakpoint is hit and execute "resume". Either set timeout or be fast so that timeout does not occur first > 6. Execute "kill -9 $EAP_PID" - optionally in VM > 7. In JDB: > 8.a. Remove breakpoint: "clear org.xnio.channels.FramedMessageChannel.receive(java.nio.ByteBuffer)" > 8.b. Resume all threads: "resume" > 9. Now dump the stack trace of jboss-cli.sh: "kill -3 $JBOSS_CLI_PID" > Found one Java-level deadlock: > ============================= > "Remoting "cli-client" read-1": > waiting to lock monitor 0x00007ff9c829b558 (object 0x0000000783433408, a java.lang.String), > which is held by "main" > "main": > waiting to lock monitor 0x00007ff9c8333c48 (object 0x00000007851ae6e0, a java.util.ArrayDeque), > which is held by "Remoting "cli-client" read-1" > Java stack information for the threads listed above: > =================================================== > "Remoting "cli-client" read-1": > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:286) > - waiting to lock <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$ChannelCloseHandler.handleClose(CLIModelControllerClient.java:269) > at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54) > at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277) > at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:532) > at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359) > at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:392) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:109) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:81) > - locked <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189) > at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:183) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72) > at org.xnio.nio.NioHandle.run(NioHandle.java:90) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:198) > "main": > at org.jboss.remoting3.remote.RemoteConnectionChannel.receiveMessage(RemoteConnectionChannel.java:361) > - waiting to lock <0x00000007851ae6e0> (a java.util.ArrayDeque) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.connectionOpened(FutureManagementChannel.java:217) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:78) > - locked <0x0000000784978a00> (a org.jboss.as.protocol.ProtocolConnectionManager) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:160) > - locked <0x0000000783433408> (a java.lang.String) > at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:120) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:123) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:98) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:980) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:841) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:817) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:282) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:250) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > 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:483) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > {noformat} > It can be easily reproduce with Eclipse as: > {noformat} > 1 start Wildfly > 2 uncomment "JAVA_OPTS="$JAVA_OPTS -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=y" in jboss-cli.sh and connect to server > 3 add two break points at > CLIModelControllerClient$ChannelCloseHandler [line: 285] - handleClose(Channel, IOException) > RemoteConnectionChannel [line: 360] - receiveMessage(Receiver) > 4 connect to 8787 from eclipse debug > 5 shutdown Wildfly > A deadlock between "main" and "cli-client" is in Eclipse debug stack. > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 10:41:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 10:41:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022822#comment-13022822 ] RH Bugzilla Integration commented on WFLY-4054: ----------------------------------------------- Hayk Hovsepyan changed the Status of [bug 1156032|https://bugzilla.redhat.com/show_bug.cgi?id=1156032] from ON_QA to MODIFIED > Unexpected attribute can be added to elements in Transactions Subsystem > ----------------------------------------------------------------------- > > Key: WFLY-4054 > URL: https://issues.jboss.org/browse/WFLY-4054 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. > When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 10:45:43 2014 From: issues at jboss.org (Stefan Erichsen (JIRA)) Date: Tue, 25 Nov 2014 10:45:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022824#comment-13022824 ] Stefan Erichsen commented on WFLY-825: -------------------------------------- Hi David, you're the best! -Dxnio.nio.old-locking=true is working! At first I was confused and tried to replace xnio-nio.jar with the one attached to this ticket. That didn't work out, after switching back to the correct jars but leaving the parameter in place it finally worked! Thank you very much! I also tried to remove the remote debugging which didn't help. Nevertheless also Thank you Tomaz for your quick help! Best regards, Stefan > JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance > -------------------------------------------------------- > > Key: WFLY-825 > URL: https://issues.jboss.org/browse/WFLY-825 > Project: WildFly > Issue Type: Bug > Components: Server > Environment: operating system - z/OS version 1.13 > JDK version info: > java version "1.7.0" > Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2)) > IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled) > J9VM - R26_Java726_SR2_20120809_0948_B118929 > JIT - r11.b01_20120808_24925 > GC - R26_Java726_SR2_20120809_0948_B118929 > J9CL - 20120809_118929) > JCL - 20120831_02 based on Oracle 7u3-b05 > Reporter: Bob Bennett > Assignee: Jason Greene > Labels: jboss > Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar > > > When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response: > Hi Bob, > > Have you contacted JBoss support for this issue? > > From my review of the javacore, every application-related thread is > waiting on some kind of internal state monitoring code. The most > prominent cause of waiting appears to be a CountdownLatch used in: > > org/jboss/as/controller/ParallelBootOperationStepHandler > $ParallelBootTransactionControl.operationPrepared > > A quick search found this possibly related JBoss bug which was > introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain > how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t > > The CountdownLatch is one of the Concurrency classes, and is very > simplistic in that it allows an application to direct threads to wait > until some certain number of actions have occured. The application code > (JBoss in this case) would need to explain how many countdowns are > required and which piece of code decrements the counter as needed. > > There's not much to say from a JVM perspective other than the threads > are all waiting for an application-level event (a call to the > "countDown()" method 'N' times where 'N' is how many JBoss initialized > the CountDownLatch to originally.) > > If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread > they think should be executing and why. A system dump of the problem > (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out... > but that won't really be of any use if we don't know what JBoss expects > them to be. > > Regards, > Java Defect Support > Please let me know if you need more info, either from myself or IBM JDK support. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 11:14:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 11:14:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4082) Upgrade Generic JMS RA to 1.0.7.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022834#comment-13022834 ] RH Bugzilla Integration commented on WFLY-4082: ----------------------------------------------- Kabir Khan changed the Status of [bug 1164213|https://bugzilla.redhat.com/show_bug.cgi?id=1164213] from MODIFIED to ON_QA > Upgrade Generic JMS RA to 1.0.7.Final > ------------------------------------- > > Key: WFLY-4082 > URL: https://issues.jboss.org/browse/WFLY-4082 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 11:17:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 11:17:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2551) AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022835#comment-13022835 ] RH Bugzilla Integration commented on WFLY-2551: ----------------------------------------------- Martin Simka changed the Status of [bug 1150821|https://bugzilla.redhat.com/show_bug.cgi?id=1150821] from ON_QA to VERIFIED > AS7.2 - JMX Datasource pool & jdbc statistics dissapear if you enable validation > -------------------------------------------------------------------------------- > > Key: WFLY-2551 > URL: https://issues.jboss.org/browse/WFLY-2551 > Project: WildFly > Issue Type: Bug > Components: JCA, JMX > Reporter: Will Tatam > Assignee: Brian Stansberry > Fix For: 9.0.0.Alpha1 > > > If you just create a basic datasource under AS 7.2 the you can view the current statistics about the pool under > jboss.as:subsystem=datasources,data-source=mySQL,statistics=pool > However, if you add the following then sometimes the statistics=pool and statistics=jdbc entries disspaear > select 1 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 11:19:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 11:19:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3937) Jackson libs are Private, should be Public In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022838#comment-13022838 ] RH Bugzilla Integration commented on WFLY-3937: ----------------------------------------------- Kabir Khan changed the Status of [bug 1094937|https://bugzilla.redhat.com/show_bug.cgi?id=1094937] from MODIFIED to CLOSED > Jackson libs are Private, should be Public > ------------------------------------------ > > Key: WFLY-3937 > URL: https://issues.jboss.org/browse/WFLY-3937 > Project: WildFly > Issue Type: Bug > Environment: EAP 6.3.0.ER2 > Reporter: Marek Novotny > Assignee: Marek Novotny > Fix For: 9.0.0.Beta1 > > > The following libraries have their module.xml files set to *private*: > * org.codehaus.jackson.jackson-core-asl > * org.codehaus.jackson.jackson-mapper-asl > * org.codehaus.jackson.jackson-jaxrs > * org.codehaus.jackson.jackson-xc > After talking with [~bill.burke], these should be *public*. > While these modules are private, the use of them creates WARNings in the stack trace. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 11:20:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 11:20:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-163) add-user only escaping first occurrence of special characters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022841#comment-13022841 ] RH Bugzilla Integration commented on WFCORE-163: ------------------------------------------------ Kabir Khan changed the Status of [bug 1150020|https://bugzilla.redhat.com/show_bug.cgi?id=1150020] from MODIFIED to ON_QA > add-user only escaping first occurrence of special characters > ------------------------------------------------------------- > > Key: WFCORE-163 > URL: https://issues.jboss.org/browse/WFCORE-163 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 11:29:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 11:29:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3435) jboss-as-infinispan_1_X.xsd schema has incorrect default value for flush-lock-timeout in write-behind In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022844#comment-13022844 ] RH Bugzilla Integration commented on WFLY-3435: ----------------------------------------------- Kabir Khan changed the Status of [bug 1007015|https://bugzilla.redhat.com/show_bug.cgi?id=1007015] from MODIFIED to ON_QA > jboss-as-infinispan_1_X.xsd schema has incorrect default value for flush-lock-timeout in write-behind > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-3435 > URL: https://issues.jboss.org/browse/WFLY-3435 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Alpha1 > > > Description of problem: > In org.infinispan.loaders.decorators.AsyncStoreConfig, the default flushLockTimeout is set to 5000. However, the default in the JBoss Infinispan schema ($JBOSS_HOME/docs/schema/jboss-as-infinispan_1_X.xsd) is set to 1. Because of this, if the thread-pool-size for write-behind is increased, then it is likely that one of the threads will not be able to obtain the state map lock within the 1 millisecond time provided by the schema default. This results in the following error: > ERROR o.i.loaders.decorators.AsyncStore.run - ISPN000051: Unexpected error > org.infinispan.CacheException: Unable to acquire lock on update map > at org.infinispan.loaders.decorators.AsyncStore.acquireLock(AsyncStore.java:293) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at org.infinispan.loaders.decorators.AsyncStore.access$900(AsyncStore.java:86) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.innerRun(AsyncStore.java:336) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.run(AsyncStore.java:312) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) ~[na:1.6.0_31] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) ~[na:1.6.0_31] > at java.lang.Thread.run(Thread.java:662) ~[na:1.6.0_31] > Version-Release number of selected component (if applicable): > Infinispan version 5.1.8 > How reproducible: > Code inspection > Steps to Reproduce: > 1. Check the default value for flush-lock-timeout in $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd > 2. Check the default value for flushLockTimeout in the org.infinispan.loaders.decorators.AsyncStoreConfig class > 3. Note the disparity > Actual results: > Default in schema is 1 > Expected results: > Default in schema is 5000 > Additional info: -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 11:30:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 11:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1521) Deployment runtime-name is not being handled properly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022845#comment-13022845 ] RH Bugzilla Integration commented on WFLY-1521: ----------------------------------------------- Kabir Khan changed the Status of [bug 964446|https://bugzilla.redhat.com/show_bug.cgi?id=964446] from MODIFIED to ON_QA > Deployment runtime-name is not being handled properly > ----------------------------------------------------- > > Key: WFLY-1521 > URL: https://issues.jboss.org/browse/WFLY-1521 > Project: WildFly > Issue Type: Feature Request > Affects Versions: 8.0.0.Alpha1 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 8.0.0.Alpha4 > > > In case archive is deployed with runtime name that does not match archive name, it breaks CLI/GUI commands. > [standalone at localhost:9999 /] deploy --runtime-name=nnn.ear /home/baranowb/redhat/git/jboss-as-quickstart/ejb-in-ear/ear/target/jboss-as-ejb-in-ear-ear-xxxx.ear > [standalone at localhost:9999 /] /deployment=jboss-as-ejb-in-ear-ear-xxxx.ear/subdeployment=jboss-as-ejb-in-ear-ejb.jar/subsystem=ejb3/stateful-session-bean=GreeterEJB:read-resource(include-runtime=true) > { > "outcome" => "failed", > "rolled-back" => true > } > 14:05:23,235 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014612: Operation ("read-attribute") failed - address: ([ > ("deployment" => "jboss-as-ejb-in-ear-ear-xxxx.ear"), > ("subdeployment" => "jboss-as-ejb-in-ear-ejb.jar"), > ("subsystem" => "ejb3"), > ("stateful-session-bean" => "GreeterEJB") > ]): org.jboss.msc.service.ServiceNotFoundException: Service service jboss.deployment.subunit."jboss-as-ejb-in-ear-ear-xxxx.ear"."jboss-as-ejb-in-ear-ejb.jar".component.GreeterEJB.START not found > at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:448) [jboss-msc-1.0.4.GA.jar:1.0.4.GA] > at org.jboss.as.controller.OperationContextImpl$OperationContextServiceRegistry.getRequiredService(OperationContextImpl.java:1068) [jboss-as-controller-7.2.2-internal-SNAPSHOT.jar:7.2.2-internal-SNAPSHOT] > at org.jboss.as.ejb3.subsystem.deployment.AbstractRuntimeMetricsHandler.executeRuntimeStep(AbstractRuntimeMetricsHandler.java:69) > at > .... > However some seem unaffected: > [standalone at localhost:9990 /] /deployment=jboss-as-ejb-in-ear-ear-xxxx.ear:read-resource > { > "outcome" => "success", > "result" => { > "content" => [{"hash" => bytes { > 0x5c, 0x22, 0x14, 0x99, 0xff, 0x23, 0x45, 0xfc, > 0x15, 0xaf, 0x1b, 0x97, 0x8c, 0x14, 0x75, 0x06, > 0xa2, 0xeb, 0xfb, 0x58 > }}], > "enabled" => true, > "name" => "jboss-as-ejb-in-ear-ear-xxxx.ear", > "persistent" => true, > "runtime-name" => "nnn.ear", > "subsystem" => undefined, > "subdeployment" => { > "jboss-as-ejb-in-ear-web.war" => undefined, > "jboss-as-ejb-in-ear-ejb.jar" => undefined > } > } > } > [standalone at localhost:9990 /] -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 11:31:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 11:31:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-195) Outbound LDAP connection in domain mode test case In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022847#comment-13022847 ] RH Bugzilla Integration commented on WFCORE-195: ------------------------------------------------ Kabir Khan changed the Status of [bug 1148400|https://bugzilla.redhat.com/show_bug.cgi?id=1148400] from MODIFIED to ON_QA > Outbound LDAP connection in domain mode test case > ------------------------------------------------- > > Key: WFCORE-195 > URL: https://issues.jboss.org/browse/WFCORE-195 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security, Test Suite > Affects Versions: 1.0.0.Alpha11 > Reporter: Ondrej Kotek > Assignee: Ondrej Kotek > Fix For: 1.0.0.Alpha11 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 11:54:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 11:54:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3690) Not possible to start XTS transaction on IPv6 with server bound to ::1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022861#comment-13022861 ] RH Bugzilla Integration commented on WFLY-3690: ----------------------------------------------- Kabir Khan changed the Status of [bug 1077156|https://bugzilla.redhat.com/show_bug.cgi?id=1077156] from MODIFIED to ON_QA > Not possible to start XTS transaction on IPv6 with server bound to ::1 > ---------------------------------------------------------------------- > > Key: WFLY-3690 > URL: https://issues.jboss.org/browse/WFLY-3690 > Project: WildFly > Issue Type: Bug > Components: Transactions, XTS > Reporter: Stefano Maestri > Assignee: Amos Feng > > Currently we have the following configuration element: > If bind address is set to ::1, then xts environment URL becomes http://::1:8080/ws-c11/ActivationService. This is incorrect, because IPv6 address with port number in it suppose to have brackets. > we could need to split url in 4 different attribute: > * protocol > * host > * port > * path > but there isn't a easy way to do the transformer by adding these new attributes. So it's just another solution to split the url and check the address if startsWith ::1, then it needs to add the brackets and join them again. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 11:58:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 11:58:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBWEB-305) No file name information in detail error when compiling the java file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBWEB-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022866#comment-13022866 ] RH Bugzilla Integration commented on JBWEB-305: ----------------------------------------------- Kabir Khan changed the Status of [bug 1155635|https://bugzilla.redhat.com/show_bug.cgi?id=1155635] from MODIFIED to ON_QA > No file name information in detail error when compiling the java file > ---------------------------------------------------------------------- > > Key: JBWEB-305 > URL: https://issues.jboss.org/browse/JBWEB-305 > Project: JBoss Web > Issue Type: Bug > Affects Versions: JBossWeb-7.4.0.GA, JBossWeb-7.5.0.GA > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > Priority: Minor > > JBossWeb does not have a fix to https://issues.apache.org/bugzilla/show_bug.cgi?id=54466. Helpful file name information can be left off of compilation errors, for example: > {code} > ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/helloworld2].[jsp]] (http-/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet jsp threw exception: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP: > JBWEB004061: An error occurred at line: 32 in the generated java file > The code of method _jspService(HttpServletRequest, HttpServletResponse) is exceeding the 65535 bytes limit > JBWEB004211: Stacktrace: > at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:85) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:69) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:451) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 12:11:40 2014 From: issues at jboss.org (Rune Steinseth (JIRA)) Date: Tue, 25 Nov 2014 12:11:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3529) UT000010: Session not found In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022878#comment-13022878 ] Rune Steinseth commented on WFLY-3529: -------------------------------------- I created a new issue for this: https://issues.jboss.org/browse/WELD-1802 > UT000010: Session not found > ---------------------------- > > Key: WFLY-3529 > URL: https://issues.jboss.org/browse/WFLY-3529 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Environment: Wildfly 8.1.0.Final , > Reporter: Youssef BIKHCHICHE > Assignee: Stuart Douglas > Attachments: WFLY-3529.tar.gz, WFLY-3529.war > > > After migration our AS from Woldfly 8.0.0 to 8.1.0 we get this issue that we think has been fixed in the previous release of wildfly. > ERREOR code : > 2014-06-20 12:45:21,092 ERROR [io.undertow.request] (default task-11) Blocking request failed HttpServerExchange{ GET /xenturion/faces/public/500.xhtml}: java.lang.RuntimeException: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:408) > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:311) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:128) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: java.lang.IllegalStateException: UT000010: Session not found cX6YRwOmoXcB8FFUdNY2r7Te > at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:319) > at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:121) > at org.springframework.security.web.context.HttpSessionSecurityContextRepository.readSecurityContextFromSession(HttpSessionSecurityContextRepository.java:144) > at org.springframework.security.web.context.HttpSessionSecurityContextRepository.loadContext(HttpSessionSecurityContextRepository.java:86) > at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82) > at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) > at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) > at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) > at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:343) > at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:260) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172) > at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:402) > ====================================================== > this issue happens after a http session invalidate action and it' not a regular problems. > Best regards, > Youssef -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 12:31:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 12:31:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1712) Erroneous name attribute on root-logger after add-handler operation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022884#comment-13022884 ] RH Bugzilla Integration commented on WFLY-1712: ----------------------------------------------- James Perkins changed the Status of [bug 1017881|https://bugzilla.redhat.com/show_bug.cgi?id=1017881] from ASSIGNED to CLOSED > Erroneous name attribute on root-logger after add-handler operation > -------------------------------------------------------------------- > > Key: WFLY-1712 > URL: https://issues.jboss.org/browse/WFLY-1712 > Project: WildFly > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Execution of the {{add-handler}} operation adds a name attribute with the handlers name to the root-logger model. > {code} > "root-logger" => {"ROOT" => { > "filter" => undefined, > "filter-spec" => undefined, > "handlers" => [ > "FILE", > "CONSOLE" > ], > "level" => "INFO", > "name" => "CONSOLE" > }} > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 14:33:39 2014 From: issues at jboss.org (Sande Gilda (JIRA)) Date: Tue, 25 Nov 2014 14:33:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console In-Reply-To: References: Message-ID: Sande Gilda created WFLY-4125: --------------------------------- Summary: javax.ejb.NoSuchEJBException should not print a stacktrace on the server console Key: WFLY-4125 URL: https://issues.jboss.org/browse/WFLY-4125 Project: WildFly Issue Type: Bug Components: EJB Reporter: Sande Gilda Assignee: David Lloyd See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 The shopping-cart quickstart has a note in the README file that states: Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 14:35:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 14:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4125: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > javax.ejb.NoSuchEJBException should not print a stacktrace on the server console > --------------------------------------------------------------------------------- > > Key: WFLY-4125 > URL: https://issues.jboss.org/browse/WFLY-4125 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Sande Gilda > Assignee: David Lloyd > > See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 > The shopping-cart quickstart has a note in the README file that states: > Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. > However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) > I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. > See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 15:00:40 2014 From: issues at jboss.org (Heiko Braun (JIRA)) Date: Tue, 25 Nov 2014 15:00:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4123) Provide a top-level 'map' operation to execute domain wide queries on the server side In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heiko Braun updated WFLY-4123: ------------------------------ Description: See https://github.com/hpehl/map-reduce {code:java} ModelNode address = new ModelNode(); address.add("profile", "*") .add("subsystem", "datasources") .add("data-source", "*"); ModelNode filter = new ModelNode(); filter.add("driver-name", "h2") .add("enabled", true); ModelNode op = new ModelNode(); op.get(OP).set(MAP_REDUCE); op.get(ADDRESS_TEMPLATE).set(address); op.get(FILTER).set(filter); // To return datasources where (driver-name == h2 || enabled == true) use // op.get(FILTER_CONJUNCT).set(false); {code} was:See https://github.com/hpehl/map-reduce > Provide a top-level 'map' operation to execute domain wide queries on the server side > ------------------------------------------------------------------------------------- > > Key: WFLY-4123 > URL: https://issues.jboss.org/browse/WFLY-4123 > Project: WildFly > Issue Type: Feature Request > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 9.0.0.Beta1 > > > See https://github.com/hpehl/map-reduce > {code:java} > ModelNode address = new ModelNode(); > address.add("profile", "*") > .add("subsystem", "datasources") > .add("data-source", "*"); > ModelNode filter = new ModelNode(); > filter.add("driver-name", "h2") > .add("enabled", true); > ModelNode op = new ModelNode(); > op.get(OP).set(MAP_REDUCE); > op.get(ADDRESS_TEMPLATE).set(address); > op.get(FILTER).set(filter); > // To return datasources where (driver-name == h2 || enabled == true) use > // op.get(FILTER_CONJUNCT).set(false); > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 15:02:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 25 Nov 2014 15:02:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-254) logging-profiles doesn't work with Apache Common Logging In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022930#comment-13022930 ] RH Bugzilla Integration commented on WFCORE-254: ------------------------------------------------ James Perkins changed the Status of [bug 1164063|https://bugzilla.redhat.com/show_bug.cgi?id=1164063] from NEW to CLOSED > logging-profiles doesn't work with Apache Common Logging > -------------------------------------------------------- > > Key: WFCORE-254 > URL: https://issues.jboss.org/browse/WFCORE-254 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Anders Welen > Assignee: James Perkins > Priority: Minor > Attachments: 87905.tar > > > The logging for one logging-profile ends up in another logging-profile from time to time. It's not sporadic as all logging will end up in the wrong place when things go wrong. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 15:23:39 2014 From: issues at jboss.org (Sande Gilda (JIRA)) Date: Tue, 25 Nov 2014 15:23:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022934#comment-13022934 ] Sande Gilda commented on WFLY-4125: ----------------------------------- This issue has also come up with stacktraces printed in the ejb-security-interceptors quickstart. It demonstrates how a secured EJB rejects unauthorized access. Again, it prints out something like the following, followed by a giant stacktrace. It would be nicer to just print the message. javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public abstract boolean org.jboss.as.quickstarts.ejb_security_interceptors.SecuredEJBRemote.roleTwoMethod() of bean: SecuredEJB is not allowed See bug https://bugzilla.redhat.com/show_bug.cgi?id=1167640 > javax.ejb.NoSuchEJBException should not print a stacktrace on the server console > --------------------------------------------------------------------------------- > > Key: WFLY-4125 > URL: https://issues.jboss.org/browse/WFLY-4125 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Sande Gilda > Assignee: David Lloyd > > See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 > The shopping-cart quickstart has a note in the README file that states: > Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. > However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) > I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. > See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 15:52:39 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 25 Nov 2014 15:52:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022940#comment-13022940 ] Stuart Douglas commented on WFLY-4125: -------------------------------------- We need a way to disable org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. This violates best practice anyway, as the interceptor both logs and re-throwns. The only reason it was included is because there is a line in the spec somewhere that says that exceptions should be logged, however this should be configurable. > javax.ejb.NoSuchEJBException should not print a stacktrace on the server console > --------------------------------------------------------------------------------- > > Key: WFLY-4125 > URL: https://issues.jboss.org/browse/WFLY-4125 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Sande Gilda > Assignee: David Lloyd > > See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 > The shopping-cart quickstart has a note in the README file that states: > Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. > However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) > I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. > See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 20:40:39 2014 From: issues at jboss.org (Chezy Palani (JIRA)) Date: Tue, 25 Nov 2014 20:40:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service In-Reply-To: References: Message-ID: Chezy Palani created WFLY-4126: ---------------------------------- Summary: java.lang.ExceptionInInitializerError when invoking BIRT service Key: WFLY-4126 URL: https://issues.jboss.org/browse/WFLY-4126 Project: WildFly Issue Type: Bug Components: Class Loading Affects Versions: 8.2.0.Final Environment: Windows 7 and JDK 1.8 Reporter: Chezy Palani Assignee: David Lloyd Fix For: 8.2.0.Final There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception. Context Path: /actuatejavacomponent Servlet Path: /iv Path Info: null Query String: __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US Stack Trace javax.servlet.ServletException: java.lang.ExceptionInInitializerError org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) javax.servlet.http.HttpServlet.service(HttpServlet.java:790) io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198) io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279) com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261) com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144) com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261) javax.servlet.http.HttpServlet.service(HttpServlet.java:687) org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) javax.servlet.http.HttpServlet.service(HttpServlet.java:790) io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 22:01:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 25 Nov 2014 22:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFLY-4126: ------------------------------ Component/s: Web (Undertow) (was: Class Loading) > java.lang.ExceptionInInitializerError when invoking BIRT service > ---------------------------------------------------------------- > > Key: WFLY-4126 > URL: https://issues.jboss.org/browse/WFLY-4126 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Windows 7 and JDK 1.8 > Reporter: Chezy Palani > Assignee: David Lloyd > Fix For: 8.2.0.Final > > > There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception. > Context Path: > /actuatejavacomponent > Servlet Path: > /iv > Path Info: > null > Query String: > __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US > Stack Trace > javax.servlet.ServletException: java.lang.ExceptionInInitializerError > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198) > io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279) > com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261) > com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144) > com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261) > javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 22:02:39 2014 From: issues at jboss.org (David Lloyd (JIRA)) Date: Tue, 25 Nov 2014 22:02:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Lloyd updated WFLY-4126: ------------------------------ Assignee: Stuart Douglas (was: David Lloyd) > java.lang.ExceptionInInitializerError when invoking BIRT service > ---------------------------------------------------------------- > > Key: WFLY-4126 > URL: https://issues.jboss.org/browse/WFLY-4126 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Windows 7 and JDK 1.8 > Reporter: Chezy Palani > Assignee: Stuart Douglas > Fix For: 8.2.0.Final > > > There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception. > Context Path: > /actuatejavacomponent > Servlet Path: > /iv > Path Info: > null > Query String: > __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US > Stack Trace > javax.servlet.ServletException: java.lang.ExceptionInInitializerError > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198) > io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279) > com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261) > com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144) > com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261) > javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 23:00:39 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Tue, 25 Nov 2014 23:00:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022966#comment-13022966 ] Stuart Douglas commented on WFLY-4126: -------------------------------------- Is there any more to that stack trace? It looks like it is missing the root cause, rhere should also be details about where the ExceptionInInitializerError was thrown from > java.lang.ExceptionInInitializerError when invoking BIRT service > ---------------------------------------------------------------- > > Key: WFLY-4126 > URL: https://issues.jboss.org/browse/WFLY-4126 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Windows 7 and JDK 1.8 > Reporter: Chezy Palani > Assignee: Stuart Douglas > Fix For: 8.2.0.Final > > > There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception. > Context Path: > /actuatejavacomponent > Servlet Path: > /iv > Path Info: > null > Query String: > __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US > Stack Trace > javax.servlet.ServletException: java.lang.ExceptionInInitializerError > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198) > io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279) > com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261) > com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144) > com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261) > javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Tue Nov 25 23:54:39 2014 From: issues at jboss.org (Ivan Kolev (JIRA)) Date: Tue, 25 Nov 2014 23:54:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3439) Websockets not working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022968#comment-13022968 ] Ivan Kolev commented on WFLY-3439: ---------------------------------- Hey, is this still not working in 8.2.0? I am trying it on Openshift and get exactly the same problem as Veli Cris, clear console but no connection to the websocket. I can't believe websocket is broken in wildfly and nobody notices! > Websockets not working > ---------------------- > > Key: WFLY-3439 > URL: https://issues.jboss.org/browse/WFLY-3439 > Project: WildFly > Issue Type: Bug > Components: Web Sockets > Affects Versions: 8.1.0.Final > Reporter: Veli Cris > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > Hi, > I deployed a .war file containing a single endpoint definition (Websocket). I can see following lines in console but nothing happens when trying to open connection from a websocket client. Same .war deployed in WildFly 8.0.0 is working. Please investigate! > The configuration is standalone. > [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /0.0.0.0:8080 > [io.undertow.websockets.jsr] (MSC service thread 1-4) UT026003: Adding annotated server endpoint ... > [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017534: Registered web context: ... > [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "web.war" (runtime-name : "web.war") -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 00:19:39 2014 From: issues at jboss.org (jaikiran pai (JIRA)) Date: Wed, 26 Nov 2014 00:19:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jaikiran pai updated WFLY-4126: ------------------------------- Fix Version/s: (was: 8.2.0.Final) > java.lang.ExceptionInInitializerError when invoking BIRT service > ---------------------------------------------------------------- > > Key: WFLY-4126 > URL: https://issues.jboss.org/browse/WFLY-4126 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Windows 7 and JDK 1.8 > Reporter: Chezy Palani > Assignee: Stuart Douglas > > There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception. > Context Path: > /actuatejavacomponent > Servlet Path: > /iv > Path Info: > null > Query String: > __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US > Stack Trace > javax.servlet.ServletException: java.lang.ExceptionInInitializerError > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198) > io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279) > com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261) > com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144) > com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261) > javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 00:35:39 2014 From: issues at jboss.org (jaikiran pai (JIRA)) Date: Wed, 26 Nov 2014 00:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022972#comment-13022972 ] jaikiran pai commented on WFLY-4125: ------------------------------------ The EJB 3 spec does mandate logging the exception, but as Stuart states, I think this should be made configurable (and default to logging it). There are users who have asked for such logs to be disabled. > javax.ejb.NoSuchEJBException should not print a stacktrace on the server console > --------------------------------------------------------------------------------- > > Key: WFLY-4125 > URL: https://issues.jboss.org/browse/WFLY-4125 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Sande Gilda > Assignee: David Lloyd > > See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 > The shopping-cart quickstart has a note in the README file that states: > Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. > However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) > I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. > See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 00:42:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Wed, 26 Nov 2014 00:42:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022973#comment-13022973 ] shinzey shinzey commented on WFLY-4096: --------------------------------------- There are no exceptions, just these error messages. I don't think a simple unit test can cover this. You can just create a simple web application, configure all the stuffs like mine and easily observe the deployment error. > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 00:44:39 2014 From: issues at jboss.org (shinzey shinzey (JIRA)) Date: Wed, 26 Nov 2014 00:44:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4096) Datasource Defined in web.xml Does Not Work with JPA Entity Manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022973#comment-13022973 ] shinzey shinzey edited comment on WFLY-4096 at 11/26/14 12:44 AM: ------------------------------------------------------------------ There are no exceptions, just these error messages. I don't think a simple unit test can cover this. You can just create a simple web application, configure all the stuffs like mine and easily observe the deployment error with a simple EJB like this: {quote} @Stateless public class TestEjb { @PersistenceContext(unitName = "xxx") private EntityManager em; } {quote} was (Author: shinzey): There are no exceptions, just these error messages. I don't think a simple unit test can cover this. You can just create a simple web application, configure all the stuffs like mine and easily observe the deployment error. > Datasource Defined in web.xml Does Not Work with JPA Entity Manager > ------------------------------------------------------------------- > > Key: WFLY-4096 > URL: https://issues.jboss.org/browse/WFLY-4096 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate, Web (JBoss Web) > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: Scott Marlow > Priority: Critical > Labels: datasource, deployment, jpa, persistence.xml, persistenceUnit > > The datasource defined in web.xml: > {quote} > > java:/datasources/test > org.apache.derby.jdbc.ClientDataSource > test > jdbc:derby://localhost:1527/test > test > test > > {quote} > The persistence unit: > {quote} > > java:/datasources/test > > {quote} > The deployment error: > {quote} > 17:57:10,813 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "WebTest.war" (runtime-name: "WebTest.war") > 17:57:11,078 INFO [org.jboss.as.jpa] (MSC service thread 1-2) JBAS011401: Read persistence.xml for wtpu > 17:57:11,172 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "WebTest.war")]) - failure description: ("JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"WebTest.war#wtpu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.datasources.test]"]) > 17:57:11,187 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "WebTest.war" (runtime-name : "WebTest.war") > 17:57:11,187 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.datasources.test (missing) dependents: [service jboss.persistenceunit."WebTest.war#wtpu".__FIRST_PHASE__] > {quote} > If I remove the persistence unit, the datasource can be successfully bound: > {quote} > 17:55:47,851 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:/datasources/test] > {quote} > The same code works as expected in GlassFish 4.1, and the @DataSourceDefinition annotation has the same issue. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 00:57:39 2014 From: issues at jboss.org (jaikiran pai (JIRA)) Date: Wed, 26 Nov 2014 00:57:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3439) Websockets not working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022974#comment-13022974 ] jaikiran pai commented on WFLY-3439: ------------------------------------ Ivan, can you create a forum thread here https://developer.jboss.org/en/wildfly/content to discuss it. There are users who have websocket working fine in WildFly 8. You state that you are using OpenShift, and that might be playing a role here. So please create a forum thread with all relevant details so that someone can help. > Websockets not working > ---------------------- > > Key: WFLY-3439 > URL: https://issues.jboss.org/browse/WFLY-3439 > Project: WildFly > Issue Type: Bug > Components: Web Sockets > Affects Versions: 8.1.0.Final > Reporter: Veli Cris > Assignee: Stuart Douglas > Fix For: 9.0.0.Alpha1 > > > Hi, > I deployed a .war file containing a single endpoint definition (Websocket). I can see following lines in console but nothing happens when trying to open connection from a websocket client. Same .war deployed in WildFly 8.0.0 is working. Please investigate! > The configuration is standalone. > [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017519: Undertow HTTP listener default listening on /0.0.0.0:8080 > [io.undertow.websockets.jsr] (MSC service thread 1-4) UT026003: Adding annotated server endpoint ... > [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017534: Registered web context: ... > [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "web.war" (runtime-name : "web.war") -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 01:00:57 2014 From: issues at jboss.org (Bartosz Baranowski (JIRA)) Date: Wed, 26 Nov 2014 01:00:57 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-129) Overlay does not work for subunits in exploded deployments. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bartosz Baranowski updated WFCORE-129: -------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/334, https://github.com/wildfly/wildfly/pull/6961 (was: https://github.com/wildfly/wildfly-core/pull/334) > Overlay does not work for subunits in exploded deployments. > ----------------------------------------------------------- > > Key: WFCORE-129 > URL: https://issues.jboss.org/browse/WFCORE-129 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha8 > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Fix For: 1.0.0.Alpha14 > > > If deployment is exploded and has subdeployments overlay wont work on files contained in said subdeployments. > Reproducers: https://github.com/baranowb/wildfly/tree/WFCORE-83-TESTS -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 01:11:39 2014 From: issues at jboss.org (SBS JIRA Integration (JIRA)) Date: Wed, 26 Nov 2014 01:11:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SBS JIRA Integration updated WFLY-4125: --------------------------------------- Forum Reference: https://developer.jboss.org/message/910596#910596 > javax.ejb.NoSuchEJBException should not print a stacktrace on the server console > --------------------------------------------------------------------------------- > > Key: WFLY-4125 > URL: https://issues.jboss.org/browse/WFLY-4125 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Sande Gilda > Assignee: David Lloyd > > See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 > The shopping-cart quickstart has a note in the README file that states: > Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. > However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) > I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. > See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 02:23:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 02:23:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-271) The description of the default scanner attribute "scan-enabled" is incorrect. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022984#comment-13022984 ] RH Bugzilla Integration commented on WFCORE-271: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1162982|https://bugzilla.redhat.com/show_bug.cgi?id=1162982] from ON_QA to VERIFIED > The description of the default scanner attribute "scan-enabled" is incorrect. > ------------------------------------------------------------------------------- > > Key: WFCORE-271 > URL: https://issues.jboss.org/browse/WFCORE-271 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > > Description of problem: The description of the 'scan-enabled' attribute states "Flag indicating that all scanning (including initial scanning at startup) should be disabled." The default value of this attribute is "true", therefore I believe the description is incorrect. > I propose that the description be changed to: "Flag indicating if all scanning (including initial scanning at startup) is enabled." -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 02:38:39 2014 From: issues at jboss.org (=?UTF-8?Q?Enrique_Gonz=C3=A1lez_Mart=C3=ADnez_=28JIRA=29?=) Date: Wed, 26 Nov 2014 02:38:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBVFS-199) RealFileSystem:exists is not case sensitive in windows leading to a compilation failure with undertow and jbossweb In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBVFS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enrique Gonz?lez Mart?nez resolved JBVFS-199. --------------------------------------------- Fix Version/s: 3.2.8.Final Resolution: Done > RealFileSystem:exists is not case sensitive in windows leading to a compilation failure with undertow and jbossweb > ------------------------------------------------------------------------------------------------------------------ > > Key: JBVFS-199 > URL: https://issues.jboss.org/browse/JBVFS-199 > Project: JBoss VFS > Issue Type: Bug > Affects Versions: 3.2.5.Final, 3.5.0.Alpha1 > Environment: Windows 64 bits > JDK 1.7.0_71 > Reporter: Enrique Gonz?lez Mart?nez > Assignee: Enrique Gonz?lez Mart?nez > Fix For: 3.2.8.Final > > > In Wildfly, during jsp compilation the lookup function uses the Classloader::getResourceAsStream that relies on VFSResourceLoader for opening an InputStream. This function is working different due to windows file system (not case sensitive). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 02:40:39 2014 From: issues at jboss.org (=?UTF-8?Q?Enrique_Gonz=C3=A1lez_Mart=C3=ADnez_=28JIRA=29?=) Date: Wed, 26 Nov 2014 02:40:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBVFS-199) RealFileSystem:exists is not case sensitive in windows leading to a compilation failure with undertow and jbossweb In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBVFS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enrique Gonz?lez Mart?nez updated JBVFS-199: -------------------------------------------- Fix Version/s: 3.5.0.Alpha1 > RealFileSystem:exists is not case sensitive in windows leading to a compilation failure with undertow and jbossweb > ------------------------------------------------------------------------------------------------------------------ > > Key: JBVFS-199 > URL: https://issues.jboss.org/browse/JBVFS-199 > Project: JBoss VFS > Issue Type: Bug > Affects Versions: 3.2.5.Final, 3.5.0.Alpha1 > Environment: Windows 64 bits > JDK 1.7.0_71 > Reporter: Enrique Gonz?lez Mart?nez > Assignee: Enrique Gonz?lez Mart?nez > Fix For: 3.2.8.Final, 3.5.0.Alpha1 > > > In Wildfly, during jsp compilation the lookup function uses the Classloader::getResourceAsStream that relies on VFSResourceLoader for opening an InputStream. This function is working different due to windows file system (not case sensitive). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 03:05:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 26 Nov 2014 03:05:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1904) NAKACK2: retransmit the last-message-missing sooner In-Reply-To: References: Message-ID: Bela Ban created JGRP-1904: ------------------------------ Summary: NAKACK2: retransmit the last-message-missing sooner Key: JGRP-1904 URL: https://issues.jboss.org/browse/JGRP-1904 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.1 When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 03:06:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 26 Nov 2014 03:06:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1904) NAKACK2: retransmit the last-message-missing sooner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-1904: --------------------------- Description: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) * It should be possible to trigger the sending programmatically, or via JMX was: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) > NAKACK2: retransmit the last-message-missing sooner > --------------------------------------------------- > > Key: JGRP-1904 > URL: https://issues.jboss.org/browse/JGRP-1904 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. > Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. > When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. > So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. > We therefore need a quicker way to detect and retransmit missing messages. > h5. Solution > * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. > * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission > * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) > * It should be possible to trigger the sending programmatically, or via JMX -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 03:06:40 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 26 Nov 2014 03:06:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1904) NAKACK2: retransmit the last-message-missing sooner In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bela Ban updated JGRP-1904: --------------------------- Description: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) * It should also be possible to trigger the sending programmatically, or via JMX was: When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. We therefore need a quicker way to detect and retransmit missing messages. h5. Solution * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) * It should be possible to trigger the sending programmatically, or via JMX > NAKACK2: retransmit the last-message-missing sooner > --------------------------------------------------- > > Key: JGRP-1904 > URL: https://issues.jboss.org/browse/JGRP-1904 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.1 > > > When we multicast messages (with {{NAKACK2}}), if the last message M is dropped (e.g. because the receiver has a full thread pool), then it will take a while for M to be retransmitted. > Currently, detection of missing messages is done in {{STABLE}}: this protocol periodically (or based on receiving a certain number of bytes) broadcasts its digest. When the coordinator has received all digests, it computes the min and broadcasts a {{STABILITY}} message. > When members receive this message, they can purge all messages below the minimum vector. Receivers also detect if the digest contains messages higher than the ones they actually received and can thus perform retransmission, if needed. > So the main purpose of {{STABLE}} is purging of messages seen by everyone, *not* detecting missing messages. It also takes a while (consensus from all members) to generate a {{STABILITY}} message, so detecting a missing message takes long. > We therefore need a quicker way to detect and retransmit missing messages. > h5. Solution > * Add a flag to {{NAKACK2}} (*not* {{STABLE}}) which - if set - periodically (or based on the number of bytes sent), broadcasts the seqno of the highest message it sent. > * When a receiver detects that it didn't receive this message, it can ask the sender for retransmission > * The task should acquiesce when no messages are missing (i.e. the highest delivered message == the highest received message) > * It should also be possible to trigger the sending programmatically, or via JMX -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 03:11:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 03:11:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-245) Add tests for suffix option on size-rotating-file-handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023001#comment-13023001 ] RH Bugzilla Integration commented on WFCORE-245: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1160541|https://bugzilla.redhat.com/show_bug.cgi?id=1160541] from ON_QA to VERIFIED > Add tests for suffix option on size-rotating-file-handler > --------------------------------------------------------- > > Key: WFCORE-245 > URL: https://issues.jboss.org/browse/WFCORE-245 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: Petr Kremensky > Assignee: James Perkins > > Add tests for WFCORE-113 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 03:39:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 03:39:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3435) jboss-as-infinispan_1_X.xsd schema has incorrect default value for flush-lock-timeout in write-behind In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023008#comment-13023008 ] RH Bugzilla Integration commented on WFLY-3435: ----------------------------------------------- Ladislav Thon changed the Status of [bug 1007015|https://bugzilla.redhat.com/show_bug.cgi?id=1007015] from ON_QA to VERIFIED > jboss-as-infinispan_1_X.xsd schema has incorrect default value for flush-lock-timeout in write-behind > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-3435 > URL: https://issues.jboss.org/browse/WFLY-3435 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 9.0.0.Alpha1 > > > Description of problem: > In org.infinispan.loaders.decorators.AsyncStoreConfig, the default flushLockTimeout is set to 5000. However, the default in the JBoss Infinispan schema ($JBOSS_HOME/docs/schema/jboss-as-infinispan_1_X.xsd) is set to 1. Because of this, if the thread-pool-size for write-behind is increased, then it is likely that one of the threads will not be able to obtain the state map lock within the 1 millisecond time provided by the schema default. This results in the following error: > ERROR o.i.loaders.decorators.AsyncStore.run - ISPN000051: Unexpected error > org.infinispan.CacheException: Unable to acquire lock on update map > at org.infinispan.loaders.decorators.AsyncStore.acquireLock(AsyncStore.java:293) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at org.infinispan.loaders.decorators.AsyncStore.access$900(AsyncStore.java:86) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.innerRun(AsyncStore.java:336) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.run(AsyncStore.java:312) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) ~[na:1.6.0_31] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) ~[na:1.6.0_31] > at java.lang.Thread.run(Thread.java:662) ~[na:1.6.0_31] > Version-Release number of selected component (if applicable): > Infinispan version 5.1.8 > How reproducible: > Code inspection > Steps to Reproduce: > 1. Check the default value for flush-lock-timeout in $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd > 2. Check the default value for flushLockTimeout in the org.infinispan.loaders.decorators.AsyncStoreConfig class > 3. Note the disparity > Actual results: > Default in schema is 1 > Expected results: > Default in schema is 5000 > Additional info: -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 03:49:39 2014 From: issues at jboss.org (Marc Dzaebel (JIRA)) Date: Wed, 26 Nov 2014 03:49:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-655) Debug: Line after "THEN" ignored In-Reply-To: References: Message-ID: Marc Dzaebel created DROOLS-655: ----------------------------------- Summary: Debug: Line after "THEN" ignored Key: DROOLS-655 URL: https://issues.jboss.org/browse/DROOLS-655 Project: Drools Issue Type: Bug Affects Versions: 6.2.0.CR2 Environment: All (Eclipse Debug) Reporter: Marc Dzaebel Assignee: Mark Proctor Priority: Minor If "THEN" is directly followed by code, the Eclipse debugger doesn't see the code, e.g. variables are not displayed in the "variables" debug view. {code} rule "" when then int i=1; System.out.println( i); // breakpoint set here end {code} Additionally, it's impossible to set breakpoints at the line of "THEN". So the indentation style is forced to always have a line for then. Even smallest rules need to take unnecessary number of lines. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 03:52:39 2014 From: issues at jboss.org (Marc Dzaebel (JIRA)) Date: Wed, 26 Nov 2014 03:52:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-655) Debug: Line after "THEN" ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marc Dzaebel updated DROOLS-655: -------------------------------- Description: If "THEN" is directly followed by code, the Eclipse debugger doesn't see the code, e.g. variables are not displayed in the "variables" debug view. {code} rule "" when then int i=1; System.out.println( i); // breakpoint set here end {code} Additionally, it's impossible to set breakpoints at the line of "THEN". So the indentation style is forced to always have a line for then. Even smallest rules need to take unnecessary number of lines. However, the above rule works. was: If "THEN" is directly followed by code, the Eclipse debugger doesn't see the code, e.g. variables are not displayed in the "variables" debug view. {code} rule "" when then int i=1; System.out.println( i); // breakpoint set here end {code} Additionally, it's impossible to set breakpoints at the line of "THEN". So the indentation style is forced to always have a line for then. Even smallest rules need to take unnecessary number of lines. > Debug: Line after "THEN" ignored > -------------------------------- > > Key: DROOLS-655 > URL: https://issues.jboss.org/browse/DROOLS-655 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.CR2 > Environment: All (Eclipse Debug) > Reporter: Marc Dzaebel > Assignee: Mark Proctor > Priority: Minor > > If "THEN" is directly followed by code, the Eclipse debugger doesn't see the code, e.g. variables are not displayed in the "variables" debug view. > {code} > rule "" > when > then int i=1; > System.out.println( i); // breakpoint set here > end > {code} > Additionally, it's impossible to set breakpoints at the line of "THEN". So the indentation style is forced to always have a line for then. Even smallest rules need to take unnecessary number of lines. However, the above rule works. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 04:07:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 04:07:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-451) Filter Apache CXF In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023016#comment-13023016 ] RH Bugzilla Integration commented on WFLY-451: ---------------------------------------------- Rostislav Svoboda changed the Status of [bug 1166502|https://bugzilla.redhat.com/show_bug.cgi?id=1166502] from ON_QA to VERIFIED > Filter Apache CXF > ----------------- > > Key: WFLY-451 > URL: https://issues.jboss.org/browse/WFLY-451 > Project: WildFly > Issue Type: Task > Components: Web Services > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 8.0.0.Alpha1 > > > Detect Apache CXF libraries in user deployment and *if* the webservices subsystem is actually being triggered for the deployment, either log a major warning or make the deployment fail. This would basically prevent later issues with users trying to deploy not properly packaged applications (e.g. the same war embedding CXF they were using on Tomcat) and making them aware of what they need to do. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 04:12:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 04:12:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3974) Move 'Channel end notification received, closing channel' to DEBUG In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023019#comment-13023019 ] RH Bugzilla Integration commented on WFLY-3974: ----------------------------------------------- Ladislav Thon changed the Status of [bug 1153281|https://bugzilla.redhat.com/show_bug.cgi?id=1153281] from ON_QA to VERIFIED > Move 'Channel end notification received, closing channel' to DEBUG > ------------------------------------------------------------------ > > Key: WFLY-3974 > URL: https://issues.jboss.org/browse/WFLY-3974 > Project: WildFly > Issue Type: Enhancement > Components: Naming > Affects Versions: 9.0.0.Alpha1 > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: 9.0.0.Beta1 > > > When a remote jms queue is located the following is seen: > 2014-09-25 16:48:29,327 INFO [org.jboss.as.naming] (Remoting "jeev6dev01_200" task-1) JBAS011806: Notification de fin de canal re?ue, fermeture du canal Channel ID 0cb79bd5 (inbound) of Remoting connection 53a1933a to /10.23.132.245:57733 > This is due to org.jboss.as.naming.NamingLogger where the following is used: > @LogMessage(level=Logger.Level.INFO) > @Message(id=11806, value="Channel end notification received, closing channel %s") > public abstract void closingChannelOnChannelEnd(Channel paramChannel); > Changin this to > @LogMessage(level=Logger.Level.DEBUG) > Would ensure that an INFO log event is not seen every time a jms message is sent to the server. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 04:19:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 04:19:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-269) CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023022#comment-13023022 ] RH Bugzilla Integration commented on WFCORE-269: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1149099|https://bugzilla.redhat.com/show_bug.cgi?id=1149099] from ON_QA to ASSIGNED > CLI freezes and it's not possible to terminate it (using Ctrl-C) in some cases > ------------------------------------------------------------------------------- > > Key: WFCORE-269 > URL: https://issues.jboss.org/browse/WFCORE-269 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > This is copy of https://bugzilla.redhat.com/show_bug.cgi?id=1149099 > Description: > The CLI freezes in phase of requesting username/password in some cases. > Reproducer > ========== > Run following command: > ./jboss-cli.sh -c << EOF > /core-service=management/security-realm=ManagementRealm/authentication=local:remove > reload > EOF -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 04:20:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 04:20:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2806) Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023023#comment-13023023 ] RH Bugzilla Integration commented on WFLY-2806: ----------------------------------------------- Rostislav Svoboda changed the Status of [bug 1166458|https://bugzilla.redhat.com/show_bug.cgi?id=1166458] from ON_QA to VERIFIED > Add check to fail deployments that use CXFServlet but have not disabled the WS subsystem > ---------------------------------------------------------------------------------------- > > Key: WFLY-2806 > URL: https://issues.jboss.org/browse/WFLY-2806 > Project: WildFly > Issue Type: Feature Request > Components: Web Services > Reporter: Kyle Lape > Assignee: Alessio Soldano > Fix For: 9.0.0.Beta1 > > > If {{CXFServlet}} is defined in an app's {{web.xml}}, the webservices subsystem should always be disabled. (Of course the preference would be to stop using {{CXFServlet}} and follow the JAX-WS way to deploy web services.) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 04:29:39 2014 From: issues at jboss.org (Marc Dzaebel (JIRA)) Date: Wed, 26 Nov 2014 04:29:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-655) Debug: Line after "THEN" ignored In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marc Dzaebel updated DROOLS-655: -------------------------------- Description: If "THEN" is directly followed by code, the Eclipse debugger doesn't see the code, e.g. variables are not displayed in the "variables" debug view. {code} rule "" when then int i=1; System.out.println( i); // breakpoint set here end {code} Additionally, it's impossible to set breakpoints at the line of "THEN". So the indentation style is forced to always have a new line after THEN. Even smallest rules need to take unnecessary number of lines. However, the above rule works. was: If "THEN" is directly followed by code, the Eclipse debugger doesn't see the code, e.g. variables are not displayed in the "variables" debug view. {code} rule "" when then int i=1; System.out.println( i); // breakpoint set here end {code} Additionally, it's impossible to set breakpoints at the line of "THEN". So the indentation style is forced to always have a line for then. Even smallest rules need to take unnecessary number of lines. However, the above rule works. > Debug: Line after "THEN" ignored > -------------------------------- > > Key: DROOLS-655 > URL: https://issues.jboss.org/browse/DROOLS-655 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.CR2 > Environment: All (Eclipse Debug) > Reporter: Marc Dzaebel > Assignee: Mark Proctor > Priority: Minor > > If "THEN" is directly followed by code, the Eclipse debugger doesn't see the code, e.g. variables are not displayed in the "variables" debug view. > {code} > rule "" > when > then int i=1; > System.out.println( i); // breakpoint set here > end > {code} > Additionally, it's impossible to set breakpoints at the line of "THEN". So the indentation style is forced to always have a new line after THEN. Even smallest rules need to take unnecessary number of lines. However, the above rule works. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 05:01:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 05:01:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4093) Changing IOR settings should require restart of jacorb subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023047#comment-13023047 ] RH Bugzilla Integration commented on WFLY-4093: ----------------------------------------------- Jan Martiska changed the Status of [bug 1080333|https://bugzilla.redhat.com/show_bug.cgi?id=1080333] from ON_QA to VERIFIED > Changing IOR settings should require restart of jacorb subsystem > ---------------------------------------------------------------- > > Key: WFLY-4093 > URL: https://issues.jboss.org/browse/WFLY-4093 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 9.0.0.Alpha1 > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: 9.0.0.Beta1 > > > When using management operations to add IOR settings, the settings don't get reflected in the IORSecConfigMetaDataService until a server reload. The management operations should mark that the jacorb subsystem needs to be restarted. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 05:45:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 05:45:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023061#comment-13023061 ] RH Bugzilla Integration commented on WFCORE-242: ------------------------------------------------ Emmanuel Hugonnet (ehsavoie) changed the Status of [bug 1162444|https://bugzilla.redhat.com/show_bug.cgi?id=1162444] from POST to ASSIGNED > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 06:00:44 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 06:00:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1650) Legacy subsystem testing needs some classloading exclusion mecanism In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023065#comment-13023065 ] RH Bugzilla Integration commented on WFLY-1650: ----------------------------------------------- Petr Kremensky changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from ON_QA to VERIFIED > Legacy subsystem testing needs some classloading exclusion mecanism > ------------------------------------------------------------------- > > Key: WFLY-1650 > URL: https://issues.jboss.org/browse/WFLY-1650 > Project: WildFly > Issue Type: Bug > Components: Logging, Test Suite > Affects Versions: 8.0.0.Alpha3 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Fix For: 8.0.0.Beta1 > > > When translation messages are used (which is the case of EAP) we have conflicts between generated $logger classes when testing submodules. > Some $logger classes exis thus they are loaded by the parent classloader before the childfirstclassloader tries to load them, thus we have a potential ClassCastException brewing. > For exemple this breaks the EAP build on a French OS. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 06:00:44 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 06:00:44 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-134) Make sure CLIWrapper doesn't use default encoding In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023066#comment-13023066 ] RH Bugzilla Integration commented on WFCORE-134: ------------------------------------------------ Petr Kremensky changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from ON_QA to VERIFIED > Make sure CLIWrapper doesn't use default encoding > ------------------------------------------------- > > Key: WFCORE-134 > URL: https://issues.jboss.org/browse/WFCORE-134 > Project: WildFly Core > Issue Type: Bug > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > CLIWrapper is using the default encoding which might lead to issue with non US locales. > Also take advantage of this fix to remove some hard coded strings from tests. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 06:16:39 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Wed, 26 Nov 2014 06:16:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4127) @TransactionAttribute ignored on SFSB PostConstruct lifecycle callback In-Reply-To: References: Message-ID: Martin Kouba created WFLY-4127: ---------------------------------- Summary: @TransactionAttribute ignored on SFSB PostConstruct lifecycle callback Key: WFLY-4127 URL: https://issues.jboss.org/browse/WFLY-4127 Project: WildFly Issue Type: Bug Components: EJB Reporter: Martin Kouba Assignee: Stuart Douglas This is a regression introduced in this commit: https://github.com/wildfly/wildfly/commit/456a624d98eaa5f5fc016ad7520290177e3771f6 Most probably {{StatefulComponentDescription}} should not pass treatRequiredAsRequiresNew=false to {{org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.Factory}} constructor. There is a CDI TCK test which can be used as a reproducer: https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jboss/cdi/tck/interceptors/tests/contract/lifecycleCallback/LifecycleCallbackInterceptorTest.java -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 06:18:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 26 Nov 2014 06:18:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1880) UDP.ip_ttl is ignored and is always 1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023069#comment-13023069 ] Bela Ban commented on JGRP-1880: -------------------------------- There's a problem on Windows where setting the TTL throws a 'not implemented' exception. This is caused by not using the right stack, forcing IPv4 with {{-Djava.net.preferIPv4Stack=true}} fixes this. > UDP.ip_ttl is ignored and is always 1 > ------------------------------------- > > Key: JGRP-1880 > URL: https://issues.jboss.org/browse/JGRP-1880 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > Since we switched from using a {{MulticastSocket}} for sending of multicast packets to a {{DatagramSocket}}, the time-to-live (TTL) of a packet is always {{1}}. The reason is that method {{setTimeToLive()}} only exists in {{MulticastSocket}}, but not in {{DatagramSocket}}. > We cannot revert the code and use a {{MulticastSocket}} to send multicasts, as this won't reveal the real IP address of the sender, but only the multicast address, and the real address is needed to drop packets at the _transport level_. > Investigate whether we could use reflection to get the {{DatagramSocketImpl}} and call {{setTimeToLive()}}. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 06:19:39 2014 From: issues at jboss.org (Bela Ban (JIRA)) Date: Wed, 26 Nov 2014 06:19:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1880) UDP.ip_ttl is ignored and is always 1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023069#comment-13023069 ] Bela Ban edited comment on JGRP-1880 at 11/26/14 6:18 AM: ---------------------------------------------------------- There's a problem on Windows where setting the TTL throws a 'not implemented' exception. This is caused by not using the right stack, forcing IPv4 with {{-Djava.net.preferIPv4Stack=true}} fixes this. Details at https://github.com/belaban/JGroups/wiki/FAQ was (Author: belaban): There's a problem on Windows where setting the TTL throws a 'not implemented' exception. This is caused by not using the right stack, forcing IPv4 with {{-Djava.net.preferIPv4Stack=true}} fixes this. > UDP.ip_ttl is ignored and is always 1 > ------------------------------------- > > Key: JGRP-1880 > URL: https://issues.jboss.org/browse/JGRP-1880 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > Since we switched from using a {{MulticastSocket}} for sending of multicast packets to a {{DatagramSocket}}, the time-to-live (TTL) of a packet is always {{1}}. The reason is that method {{setTimeToLive()}} only exists in {{MulticastSocket}}, but not in {{DatagramSocket}}. > We cannot revert the code and use a {{MulticastSocket}} to send multicasts, as this won't reveal the real IP address of the sender, but only the multicast address, and the real address is needed to drop packets at the _transport level_. > Investigate whether we could use reflection to get the {{DatagramSocketImpl}} and call {{setTimeToLive()}}. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 06:22:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 06:22:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023070#comment-13023070 ] RH Bugzilla Integration commented on WFCORE-242: ------------------------------------------------ Tomas Hofman changed the Status of [bug 1162444|https://bugzilla.redhat.com/show_bug.cgi?id=1162444] from ASSIGNED to POST > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 07:07:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 07:07:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-145) CLI run-batch command cannot process files with comments or blank lines In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023112#comment-13023112 ] RH Bugzilla Integration commented on WFCORE-145: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1148642|https://bugzilla.redhat.com/show_bug.cgi?id=1148642] from ON_QA to VERIFIED > CLI run-batch command cannot process files with comments or blank lines > ----------------------------------------------------------------------- > > Key: WFCORE-145 > URL: https://issues.jboss.org/browse/WFCORE-145 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha8 > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > In the JBoss CLI tool, the "run-batch --file=script.cli" command cannot > successfully process lines that start with "#" or blank lines. Comments and > blank lines help readability when creating cli batch scripts. > However, running the batch file containing comments/blank lines as a parameter > to jboss-cli.sh works just fine (./jboss-cli.sh -c --file=script.cli). This > difference in accepted syntax creates some confusion for users who are new to > the CLI tool. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 07:09:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 07:09:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4082) Upgrade Generic JMS RA to 1.0.7.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023113#comment-13023113 ] RH Bugzilla Integration commented on WFLY-4082: ----------------------------------------------- Miroslav Novak changed the Status of [bug 1164213|https://bugzilla.redhat.com/show_bug.cgi?id=1164213] from ON_QA to VERIFIED > Upgrade Generic JMS RA to 1.0.7.Final > ------------------------------------- > > Key: WFLY-4082 > URL: https://issues.jboss.org/browse/WFLY-4082 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 07:22:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 07:22:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3969) HeaderTokenParser doesn't parse correctly values which includes a quote In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023115#comment-13023115 ] RH Bugzilla Integration commented on WFLY-3969: ----------------------------------------------- Josef Cacek changed the Status of [bug 1150024|https://bugzilla.redhat.com/show_bug.cgi?id=1150024] from ON_QA to VERIFIED > HeaderTokenParser doesn't parse correctly values which includes a quote > ----------------------------------------------------------------------- > > Key: WFLY-3969 > URL: https://issues.jboss.org/browse/WFLY-3969 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Josef Cacek > Assignee: Stuart Douglas > Priority: Critical > Fix For: 8.2.0.Final, 9.0.0.Beta1 > > > The header parser doesn't work correctly if a parsed value contains quote character ("). The problem is, the parser is in phase of searching a LAST_QUOTE and it doesn't check if the found quote character is escaped or not. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 07:50:40 2014 From: issues at jboss.org (Sande Gilda (JIRA)) Date: Wed, 26 Nov 2014 07:50:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4125) javax.ejb.NoSuchEJBException should not print a stacktrace on the server console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023129#comment-13023129 ] Sande Gilda commented on WFLY-4125: ----------------------------------- Can it be configured to log the exception message, but suppress the stacktrace? > javax.ejb.NoSuchEJBException should not print a stacktrace on the server console > --------------------------------------------------------------------------------- > > Key: WFLY-4125 > URL: https://issues.jboss.org/browse/WFLY-4125 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Sande Gilda > Assignee: David Lloyd > > See related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1167293 > The shopping-cart quickstart has a note in the README file that states: > Note: You also see the following EJB Invocation failed and NoSuchEJBException messages in the server log. This is the expected result because method is annotated with @Remove. This means the next invocation after the shopping cart checkout fails because the container has destroyed the instance and it is no longer available. > However, usually people see the stacktrace in the server and assume something is terribly wrong. (see https://bugzilla.redhat.com/show_bug.cgi?id=910868) > I spoke with Brad Maxwell and David M Lloyd to see if there is a way to suppress the stacktrace and only print the exception message, but it is not possible. The stacktrace doesn't really provide any additional information, and since it's thrown, the caller has access to it. > See related bug for JBoss EAP 6.4: https://bugzilla.redhat.com/show_bug.cgi?id=1167983 > David said: Looks like the place to make this change would be in org.jboss.as.ejb3.component.interceptors.LoggingInterceptor. Maybe a specific catch clause for exception types to not log? -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 07:51:39 2014 From: issues at jboss.org (Gabor Auth (JIRA)) Date: Wed, 26 Nov 2014 07:51:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3718) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023132#comment-13023132 ] Gabor Auth commented on WFLY-3718: ---------------------------------- Another stacktrace from WildFly 8.2.0.Final: {code} ==> /home/wildfly/wildfly-8.2.0.Final/domain/servers/server-two/log/server.log <== 2014-11-26 13:46:29,668 ERROR [io.undertow.request] (default task-8) UT005023: Exception handling request to /frontend/index.jsp: java.lang.NullPointerException at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51) at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:319) at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:308) at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:163) at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115) at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:688) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:718) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11] {code} > UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-3718 > URL: https://issues.jboss.org/browse/WFLY-3718 > Project: WildFly > Issue Type: Bug > Components: Clustering, Web (Undertow) > Affects Versions: 8.1.0.Final > Environment: WildFly 8.1.0.Final > Reporter: Gabor Auth > Assignee: Paul Ferraro > Fix For: 8.2.0.Final > > > 2014-07-30 02:12:30,088 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException > at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164) > at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11] > 2014-07-30 02:12:30,786 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /frontend/images/favicon.ico}: java.lang.NullPointerException > at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309) > at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164) > at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) > at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) > at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:711) > at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:137) > at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11] -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 07:59:39 2014 From: issues at jboss.org (=?UTF-8?Q?Tihomir_Me=C5=A1=C4=8Di=C4=87_=28JIRA=29?=) Date: Wed, 26 Nov 2014 07:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tihomir Me??i? updated DROOLS-654: ---------------------------------- Summary: Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config (was: Dynamic update with KieContainer.updateToVersion() not working in STREAM mode) > Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config > ---------------------------------------------------------------------------------------------------- > > Key: DROOLS-654 > URL: https://issues.jboss.org/browse/DROOLS-654 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: Ubuntu Linux > Reporter: Tihomir Me??i? > Assignee: Mark Proctor > Priority: Blocker > > I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: > {{KieBaseConfiguration config = KieServices.Factory.get()}} > {{.newKieBaseConfiguration();}} > {{config.setOption(EventProcessingOption.STREAM);}} > > {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} > {{KieSession ksession = kc.newKieBase(config).newKieSession();}} > After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): > {{kc.updateToVersion( ... newReleaseId... );}} > It seems like all of the facts are removed from the session, and my rules are no longer triggered. > When I do not use the configuration object when creating the session and just use: > {{KieSession ksession = kc.newKieSession();}} > then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 08:00:43 2014 From: issues at jboss.org (=?UTF-8?Q?Tihomir_Me=C5=A1=C4=8Di=C4=87_=28JIRA=29?=) Date: Wed, 26 Nov 2014 08:00:43 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tihomir Me??i? updated DROOLS-654: ---------------------------------- Description: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{KieBaseConfiguration config = KieServices.Factory.get()}} {{.newKieBaseConfiguration();}} {{config.setOption(EventProcessingOption.STREAM);}} {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} {{KieSession ksession = kc.newKieBase(config).newKieSession();}} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{kc.updateToVersion( ... newReleaseId... );}} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{KieSession ksession = kc.newKieSession();}} then, everything works as expected. However, this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). was: I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: {{KieBaseConfiguration config = KieServices.Factory.get()}} {{.newKieBaseConfiguration();}} {{config.setOption(EventProcessingOption.STREAM);}} {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} {{KieSession ksession = kc.newKieBase(config).newKieSession();}} After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): {{kc.updateToVersion( ... newReleaseId... );}} It seems like all of the facts are removed from the session, and my rules are no longer triggered. When I do not use the configuration object when creating the session and just use: {{KieSession ksession = kc.newKieSession();}} then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). > Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config > ---------------------------------------------------------------------------------------------------- > > Key: DROOLS-654 > URL: https://issues.jboss.org/browse/DROOLS-654 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: Ubuntu Linux > Reporter: Tihomir Me??i? > Assignee: Mark Proctor > Priority: Blocker > > I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: > {{KieBaseConfiguration config = KieServices.Factory.get()}} > {{.newKieBaseConfiguration();}} > {{config.setOption(EventProcessingOption.STREAM);}} > > {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} > {{KieSession ksession = kc.newKieBase(config).newKieSession();}} > After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): > {{kc.updateToVersion( ... newReleaseId... );}} > It seems like all of the facts are removed from the session, and my rules are no longer triggered. > When I do not use the configuration object when creating the session and just use: > {{KieSession ksession = kc.newKieSession();}} > then, everything works as expected. However, this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 08:09:39 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Wed, 26 Nov 2014 08:09:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-281) Unable to check result "undefined" in cli In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Loubyansky moved WFLY-4118 to WFCORE-281: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-281 (was: WFLY-4118) Affects Version/s: 1.0.0.Alpha13 (was: 9.0.0.Alpha1) Component/s: CLI (was: CLI) Fix Version/s: (was: 9.0.0.Beta1) > Unable to check result "undefined" in cli > ----------------------------------------- > > Key: WFCORE-281 > URL: https://issues.jboss.org/browse/WFCORE-281 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha13 > Reporter: Joe Wertz > Assignee: Joe Wertz > Priority: Minor > > if-else constructs in the CLI can't compare against undefined attribute results. > Attempt to create any 'if (result == undefined)' algorithms will always return false. The value-comparison can't handle undefined attributes. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 08:10:39 2014 From: issues at jboss.org (Emanuel Muckenhuber (JIRA)) Date: Wed, 26 Nov 2014 08:10:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-282) Wildcard operations that span multiple processes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emanuel Muckenhuber moved WFLY-723 to WFCORE-282: ------------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-282 (was: WFLY-723) Issue Type: Task (was: Feature Request) Component/s: Domain Management (was: Domain Management) Fix Version/s: 1.0.0.Beta1 (was: Awaiting Volunteers) > Wildcard operations that span multiple processes > ------------------------------------------------ > > Key: WFCORE-282 > URL: https://issues.jboss.org/browse/WFCORE-282 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Labels: as7-ignored > Fix For: 1.0.0.Beta1 > > > Handle host=* and host=y,server=* type operations. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 08:14:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 26 Nov 2014 08:14:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-283) SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-283: --------------------------------------- Summary: SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting Key: WFCORE-283 URL: https://issues.jboss.org/browse/WFCORE-283 Project: WildFly Core Issue Type: Bug Components: Domain Management, Remoting, Security Affects Versions: 1.0.0.Alpha13 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha14 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 08:29:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 08:29:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023159#comment-13023159 ] RH Bugzilla Integration commented on WFCORE-213: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1018026|https://bugzilla.redhat.com/show_bug.cgi?id=1018026] from ON_QA to ASSIGNED > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 08:42:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 08:42:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-163) add-user only escaping first occurrence of special characters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023170#comment-13023170 ] RH Bugzilla Integration commented on WFCORE-163: ------------------------------------------------ Josef Cacek changed the Status of [bug 1150020|https://bugzilla.redhat.com/show_bug.cgi?id=1150020] from ON_QA to VERIFIED > add-user only escaping first occurrence of special characters > ------------------------------------------------------------- > > Key: WFCORE-163 > URL: https://issues.jboss.org/browse/WFCORE-163 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha10 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 08:55:39 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 26 Nov 2014 08:55:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-199) The entire kie build should work on maven 3.1.0 too In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023200#comment-13023200 ] Geoffrey De Smet commented on DROOLS-199: ----------------------------------------- @mbiarnes For kie 6.3, we should move to maven 3.2.x to avoid known issues in the very old maven version that we're using now. This means: - enforcing at least 3.2.3 (because 3.2.2 has a nasty bug) - notifying our developers in advance This doesn't apply to kie 6.2, because productization's infrastructure isn't ready. Productization has been warned today that this will happen for kie 6.3, so they can prepare for this for 6.3. > The entire kie build should work on maven 3.1.0 too > --------------------------------------------------- > > Key: DROOLS-199 > URL: https://issues.jboss.org/browse/DROOLS-199 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > To reproduce: > - Install maven 3.1.0 > - Run mvn-all.sh clean install -Dfull > Note: Any changes to the pom must still allow them to run with 3.0.5 too. > 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. > So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). > 2) There might be other surprises... -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 08:59:40 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 26 Nov 2014 08:59:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-199) The entire kie build should work on maven 3.1.0 too In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023200#comment-13023200 ] Geoffrey De Smet edited comment on DROOLS-199 at 11/26/14 8:58 AM: ------------------------------------------------------------------- @mbiarnes For kie 6.3, we should move to maven 3.2.x to avoid known issues in the very old maven version that we're using now. This means: - enforcing at least 3.2.3 (because 3.2.2 has a nasty bug) - notifying our developers in advance This doesn't apply to kie 6.2, because productization's infrastructure isn't ready. Productization (Julian) has been notified today that this will happen for kie 6.3, so they can prepare for this for 6.3. was (Author: ge0ffrey): @mbiarnes For kie 6.3, we should move to maven 3.2.x to avoid known issues in the very old maven version that we're using now. This means: - enforcing at least 3.2.3 (because 3.2.2 has a nasty bug) - notifying our developers in advance This doesn't apply to kie 6.2, because productization's infrastructure isn't ready. Productization has been warned today that this will happen for kie 6.3, so they can prepare for this for 6.3. > The entire kie build should work on maven 3.1.0 too > --------------------------------------------------- > > Key: DROOLS-199 > URL: https://issues.jboss.org/browse/DROOLS-199 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > To reproduce: > - Install maven 3.1.0 > - Run mvn-all.sh clean install -Dfull > Note: Any changes to the pom must still allow them to run with 3.0.5 too. > 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. > So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). > 2) There might be other surprises... -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 08:59:40 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 26 Nov 2014 08:59:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-199) The entire kie build should work on maven 3.1.0 too In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-199: ------------------------------------ Priority: Critical (was: Major) > The entire kie build should work on maven 3.1.0 too > --------------------------------------------------- > > Key: DROOLS-199 > URL: https://issues.jboss.org/browse/DROOLS-199 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > To reproduce: > - Install maven 3.1.0 > - Run mvn-all.sh clean install -Dfull > Note: Any changes to the pom must still allow them to run with 3.0.5 too. > 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. > So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). > 2) There might be other surprises... -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 08:59:40 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 26 Nov 2014 08:59:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-199) The entire kie build should move maven from 3.0.5 to 3.2.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-199: ------------------------------------ Summary: The entire kie build should move maven from 3.0.5 to 3.2.x (was: The entire kie build should work on maven 3.1.0 too) > The entire kie build should move maven from 3.0.5 to 3.2.x > ---------------------------------------------------------- > > Key: DROOLS-199 > URL: https://issues.jboss.org/browse/DROOLS-199 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > To reproduce: > - Install maven 3.1.0 > - Run mvn-all.sh clean install -Dfull > Note: Any changes to the pom must still allow them to run with 3.0.5 too. > 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. > So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). > 2) There might be other surprises... -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:00:42 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 26 Nov 2014 09:00:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-199) The entire kie build should move maven from 3.0.5 to 3.2.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-199: ------------------------------------ Description: Old description: To reproduce: - Install maven 3.1.0 - Run mvn-all.sh clean install -Dfull Note: Any changes to the pom must still allow them to run with 3.0.5 too. 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). 2) There might be other surprises... was: To reproduce: - Install maven 3.1.0 - Run mvn-all.sh clean install -Dfull Note: Any changes to the pom must still allow them to run with 3.0.5 too. 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). 2) There might be other surprises... > The entire kie build should move maven from 3.0.5 to 3.2.x > ---------------------------------------------------------- > > Key: DROOLS-199 > URL: https://issues.jboss.org/browse/DROOLS-199 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > Old description: > To reproduce: > - Install maven 3.1.0 > - Run mvn-all.sh clean install -Dfull > Note: Any changes to the pom must still allow them to run with 3.0.5 too. > 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. > So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). > 2) There might be other surprises... -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:00:42 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 26 Nov 2014 09:00:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-199) The entire kie 6.3 build should move maven from 3.0.5 to 3.2.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-199: ------------------------------------ Summary: The entire kie 6.3 build should move maven from 3.0.5 to 3.2.x (was: The entire kie build should move maven from 3.0.5 to 3.2.x) > The entire kie 6.3 build should move maven from 3.0.5 to 3.2.x > -------------------------------------------------------------- > > Key: DROOLS-199 > URL: https://issues.jboss.org/browse/DROOLS-199 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > Old description: > To reproduce: > - Install maven 3.1.0 > - Run mvn-all.sh clean install -Dfull > Note: Any changes to the pom must still allow them to run with 3.0.5 too. > 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. > So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). > 2) There might be other surprises... -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:04:39 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 26 Nov 2014 09:04:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-656) The blessed repo's should not accept a force push In-Reply-To: References: Message-ID: Geoffrey De Smet created DROOLS-656: --------------------------------------- Summary: The blessed repo's should not accept a force push Key: DROOLS-656 URL: https://issues.jboss.org/browse/DROOLS-656 Project: Drools Issue Type: Task Reporter: Geoffrey De Smet Assignee: Michael Biarnes Kiefer Priority: Critical If someone ever git forces pushes to a blessed repo all hell will break loose. We can prevent git forces pushes, as explained here: http://stackoverflow.com/questions/1754491/is-there-a-way-to-configure-git-repository-to-reject-git-push-force Requirements: - Enable this on 1 new dummy blessed repository - Prove you cannot force push to - Prove you can fork it and force push to your fork. - Delete the dummy blessed repository - If that works well, enable it on the real blessed repositories -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:04:39 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 26 Nov 2014 09:04:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-656) The blessed repo's should not accept a git force push In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-656: ------------------------------------ Summary: The blessed repo's should not accept a git force push (was: The blessed repo's should not accept a force push) > The blessed repo's should not accept a git force push > ----------------------------------------------------- > > Key: DROOLS-656 > URL: https://issues.jboss.org/browse/DROOLS-656 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > If someone ever git forces pushes to a blessed repo all hell will break loose. > We can prevent git forces pushes, as explained here: > http://stackoverflow.com/questions/1754491/is-there-a-way-to-configure-git-repository-to-reject-git-push-force > Requirements: > - Enable this on 1 new dummy blessed repository > - Prove you cannot force push to > - Prove you can fork it and force push to your fork. > - Delete the dummy blessed repository > - If that works well, enable it on the real blessed repositories -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:05:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 09:05:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-865) Setting transaction timeout on UserTransaction leaks to the thread and doesn't get cleared In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023219#comment-13023219 ] RH Bugzilla Integration commented on WFLY-865: ---------------------------------------------- Jan Martiska changed the Status of [bug 900984|https://bugzilla.redhat.com/show_bug.cgi?id=900984] from ON_QA to VERIFIED > Setting transaction timeout on UserTransaction leaks to the thread and doesn't get cleared > ------------------------------------------------------------------------------------------ > > Key: WFLY-865 > URL: https://issues.jboss.org/browse/WFLY-865 > Project: WildFly > Issue Type: Bug > Components: EE, Transactions > Reporter: jaikiran pai > Assignee: David Lloyd > > A user has reported (with an example) that setting a transaction timeout on the UserTransaction will leak the timeout onto the thread and subsequent transaction creation on that thread uses the leaked value instead of new values. > More details in the referenced forum thread. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:06:40 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 26 Nov 2014 09:06:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-656) The blessed repo's should not accept a git force push In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet updated DROOLS-656: ------------------------------------ Description: If someone ever git forces pushes to a blessed repo all hell will break loose. We can prevent git forces pushes, as explained here: http://stackoverflow.com/questions/1754491/is-there-a-way-to-configure-git-repository-to-reject-git-push-force Force pushing on blessed repo's is very bad, but force pushing on forks is very common. Requirements: - Enable this on 1 new dummy blessed repository - Prove you cannot force push to - Prove you can fork it and force push to your fork. - Delete the dummy blessed repository - If that works well, enable it on the real blessed repositories was: If someone ever git forces pushes to a blessed repo all hell will break loose. We can prevent git forces pushes, as explained here: http://stackoverflow.com/questions/1754491/is-there-a-way-to-configure-git-repository-to-reject-git-push-force Requirements: - Enable this on 1 new dummy blessed repository - Prove you cannot force push to - Prove you can fork it and force push to your fork. - Delete the dummy blessed repository - If that works well, enable it on the real blessed repositories > The blessed repo's should not accept a git force push > ----------------------------------------------------- > > Key: DROOLS-656 > URL: https://issues.jboss.org/browse/DROOLS-656 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > If someone ever git forces pushes to a blessed repo all hell will break loose. > We can prevent git forces pushes, as explained here: > http://stackoverflow.com/questions/1754491/is-there-a-way-to-configure-git-repository-to-reject-git-push-force > Force pushing on blessed repo's is very bad, but force pushing on forks is very common. > Requirements: > - Enable this on 1 new dummy blessed repository > - Prove you cannot force push to > - Prove you can fork it and force push to your fork. > - Delete the dummy blessed repository > - If that works well, enable it on the real blessed repositories -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:11:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 09:11:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JBWEB-305) No file name information in detail error when compiling the java file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBWEB-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023234#comment-13023234 ] RH Bugzilla Integration commented on JBWEB-305: ----------------------------------------------- Radim Hatlapatka changed the Status of [bug 1155635|https://bugzilla.redhat.com/show_bug.cgi?id=1155635] from ON_QA to VERIFIED > No file name information in detail error when compiling the java file > ---------------------------------------------------------------------- > > Key: JBWEB-305 > URL: https://issues.jboss.org/browse/JBWEB-305 > Project: JBoss Web > Issue Type: Bug > Affects Versions: JBossWeb-7.4.0.GA, JBossWeb-7.5.0.GA > Reporter: Aaron Ogburn > Assignee: Remy Maucherat > Priority: Minor > > JBossWeb does not have a fix to https://issues.apache.org/bugzilla/show_bug.cgi?id=54466. Helpful file name information can be left off of compilation errors, for example: > {code} > ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/helloworld2].[jsp]] (http-/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet jsp threw exception: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP: > JBWEB004061: An error occurred at line: 32 in the generated java file > The code of method _jspService(HttpServletRequest, HttpServletResponse) is exceeding the 65535 bytes limit > JBWEB004211: Stacktrace: > at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:85) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:69) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:451) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:13:40 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Wed, 26 Nov 2014 09:13:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-146) Use .gitattributes to force linux line endings for all text files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geoffrey De Smet reassigned DROOLS-146: --------------------------------------- Assignee: Michael Biarnes Kiefer (was: Geoffrey De Smet) This has worked well for months on the optaplanner repository. Michael, 1) All the other blessed repositories should now also get that .gitattributes file (copy it for the optaplanner repo). Possibly improve it first before copying. 2) Clean up all previous errors, as stated in the important above. Shells scripts like dos2unix etc can help here. All java files etc were dos2unixed 2 years ago, but we've seen many contributions since then ... > Use .gitattributes to force linux line endings for all text files > ----------------------------------------------------------------- > > Key: DROOLS-146 > URL: https://issues.jboss.org/browse/DROOLS-146 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > With .gitattributes we can force all java files etc to have linux file endings. > I am experimenting with this in the optaplanner repository: > https://github.com/droolsjbpm/optaplanner/commit/40dca629262568d5e5abb379655d0ea65aef19a6 > If it works well, we'll want to compile a good overall .gitattributes file and commit it to all droolsjbpm repositories. > During the refactor to .gitattributes, execute this script to detect and fix all previous errors: > https://help.github.com/articles/dealing-with-line-endings#re-normalizing-a-repository > *Important:* > In OptaPlanner we just committed the file without "fixing all previous errors". It turned out we had 2. > The person who adds the .gitattributes file doesn't get a problem, but other people who clone a new repository > get immediate modifications to incorrect files. This is a PITA. > So *after the commit .gitattributes files, all previous errors need to be fixed for and verified by doing a new clone and a git status on that new clone.* -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:18:39 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Wed, 26 Nov 2014 09:18:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-284) Rewrite CLI FileArgumentTestCase In-Reply-To: References: Message-ID: Alexey Loubyansky created WFCORE-284: ---------------------------------------- Summary: Rewrite CLI FileArgumentTestCase Key: WFCORE-284 URL: https://issues.jboss.org/browse/WFCORE-284 Project: WildFly Core Issue Type: Task Components: CLI Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky The test has been failing sporadically for awhile. One of the problems is to figure out the conditions under which the test fails. They haven't been determined so far. Perhaps, attempts to simplify and clean up the logic in the test will help. The test is org.jboss.as.test.integration.management.cli.FileArgumentTestCase -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:19:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 09:19:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-284) Rewrite CLI FileArgumentTestCase In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-284: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=900632 > Rewrite CLI FileArgumentTestCase > -------------------------------- > > Key: WFCORE-284 > URL: https://issues.jboss.org/browse/WFCORE-284 > Project: WildFly Core > Issue Type: Task > Components: CLI > Reporter: Alexey Loubyansky > Assignee: Alexey Loubyansky > > The test has been failing sporadically for awhile. One of the problems is to figure out the conditions under which the test fails. They haven't been determined so far. Perhaps, attempts to simplify and clean up the logic in the test will help. > The test is org.jboss.as.test.integration.management.cli.FileArgumentTestCase -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:25:39 2014 From: issues at jboss.org (Heiko Braun (JIRA)) Date: Wed, 26 Nov 2014 09:25:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4123) Provide a 'map_reduce' operation to execute domain wide queries on the server side In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heiko Braun updated WFLY-4123: ------------------------------ Summary: Provide a 'map_reduce' operation to execute domain wide queries on the server side (was: Provide a top-level 'map' operation to execute domain wide queries on the server side) > Provide a 'map_reduce' operation to execute domain wide queries on the server side > ---------------------------------------------------------------------------------- > > Key: WFLY-4123 > URL: https://issues.jboss.org/browse/WFLY-4123 > Project: WildFly > Issue Type: Feature Request > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 9.0.0.Beta1 > > > See https://github.com/hpehl/map-reduce > {code:java} > ModelNode address = new ModelNode(); > address.add("profile", "*") > .add("subsystem", "datasources") > .add("data-source", "*"); > ModelNode filter = new ModelNode(); > filter.add("driver-name", "h2") > .add("enabled", true); > ModelNode op = new ModelNode(); > op.get(OP).set(MAP_REDUCE); > op.get(ADDRESS_TEMPLATE).set(address); > op.get(FILTER).set(filter); > // To return datasources where (driver-name == h2 || enabled == true) use > // op.get(FILTER_CONJUNCT).set(false); > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:25:39 2014 From: issues at jboss.org (Heiko Braun (JIRA)) Date: Wed, 26 Nov 2014 09:25:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4123) Provide a 'map-reduce' operation to execute domain wide queries on the server side In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Heiko Braun updated WFLY-4123: ------------------------------ Summary: Provide a 'map-reduce' operation to execute domain wide queries on the server side (was: Provide a 'map_reduce' operation to execute domain wide queries on the server side) > Provide a 'map-reduce' operation to execute domain wide queries on the server side > ---------------------------------------------------------------------------------- > > Key: WFLY-4123 > URL: https://issues.jboss.org/browse/WFLY-4123 > Project: WildFly > Issue Type: Feature Request > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 9.0.0.Beta1 > > > See https://github.com/hpehl/map-reduce > {code:java} > ModelNode address = new ModelNode(); > address.add("profile", "*") > .add("subsystem", "datasources") > .add("data-source", "*"); > ModelNode filter = new ModelNode(); > filter.add("driver-name", "h2") > .add("enabled", true); > ModelNode op = new ModelNode(); > op.get(OP).set(MAP_REDUCE); > op.get(ADDRESS_TEMPLATE).set(address); > op.get(FILTER).set(filter); > // To return datasources where (driver-name == h2 || enabled == true) use > // op.get(FILTER_CONJUNCT).set(false); > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:30:40 2014 From: issues at jboss.org (Alexey Loubyansky (JIRA)) Date: Wed, 26 Nov 2014 09:30:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-285) cli tab completion gets confused by double slash In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Loubyansky moved WFLY-4084 to WFCORE-285: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-285 (was: WFLY-4084) Affects Version/s: 1.0.0.Alpha13 (was: 9.0.0.Alpha1) Component/s: CLI (was: CLI) > cli tab completion gets confused by double slash > ------------------------------------------------ > > Key: WFCORE-285 > URL: https://issues.jboss.org/browse/WFCORE-285 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Affects Versions: 1.0.0.Alpha13 > Reporter: Tom Fonteyne > Assignee: Alexey Loubyansky > Priority: Minor > > Using two slashes in a CLI path and hitting TAB confuses the auto-completion -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:33:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 09:33:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-213) Clean unreferenced items from the content repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023283#comment-13023283 ] RH Bugzilla Integration commented on WFCORE-213: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1018026|https://bugzilla.redhat.com/show_bug.cgi?id=1018026] from ASSIGNED to VERIFIED > Clean unreferenced items from the content repository > ---------------------------------------------------- > > Key: WFCORE-213 > URL: https://issues.jboss.org/browse/WFCORE-213 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emmanuel Hugonnet > Fix For: 1.0.0.Alpha14 > > > The algorithm for removing unused deployments from the content repository is based on doing this as part of undeploy operation execution. This doesn't cover cases where the content is never explicitly undeployed. For example: > 1) Scanner content that is updated when the server is offline; the old content will not have been "undeployed" during shutdown, and on startup the new content will be installed. > 2) Similar issues with deployments generated from module resources (see "A Mixed Approach on https://community.jboss.org/wiki/ExtendingAS7). When the server shuts down, there is no "subsystem remove" as part of shutdown, so the content added during start will not be removed. > Note that the content repository can include things other than deployments. Currently it also includes management-client-content (specifically rollout plans) and can potentially include anything. This is why it's a "content repository" and not a "deployment repository." The solution for this needs to deal with all cases. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:37:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 09:37:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1721) AUTH and ENCRYPT protocols configured with plain text passwords In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023290#comment-13023290 ] RH Bugzilla Integration commented on JGRP-1721: ----------------------------------------------- Tristan Tarrant changed the Status of [bug 1021819|https://bugzilla.redhat.com/show_bug.cgi?id=1021819] from NEW to ASSIGNED > AUTH and ENCRYPT protocols configured with plain text passwords > --------------------------------------------------------------- > > Key: JGRP-1721 > URL: https://issues.jboss.org/browse/JGRP-1721 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.4 > Reporter: Martin Gencur > Assignee: Bela Ban > Fix For: 3.5 > > > The following parameters of AUTH protocol are stored as plain text: > * keystore_password > The following parameters of ENCRYPT protocol are stored as plain text: > * store_password > * key_password > Example: > {code} > > {code} > Requirements for storing passwords: https://docspace.corp.redhat.com/docs/DOC-131628 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:47:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 09:47:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3690) Not possible to start XTS transaction on IPv6 with server bound to ::1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023304#comment-13023304 ] RH Bugzilla Integration commented on WFLY-3690: ----------------------------------------------- Ondrej Chaloupka changed the Status of [bug 1077156|https://bugzilla.redhat.com/show_bug.cgi?id=1077156] from ON_QA to VERIFIED > Not possible to start XTS transaction on IPv6 with server bound to ::1 > ---------------------------------------------------------------------- > > Key: WFLY-3690 > URL: https://issues.jboss.org/browse/WFLY-3690 > Project: WildFly > Issue Type: Bug > Components: Transactions, XTS > Reporter: Stefano Maestri > Assignee: Amos Feng > > Currently we have the following configuration element: > If bind address is set to ::1, then xts environment URL becomes http://::1:8080/ws-c11/ActivationService. This is incorrect, because IPv6 address with port number in it suppose to have brackets. > we could need to split url in 4 different attribute: > * protocol > * host > * port > * path > but there isn't a easy way to do the transformer by adding these new attributes. So it's just another solution to split the url and check the address if startsWith ::1, then it needs to add the brackets and join them again. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:55:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 09:55:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-259) Improve realm readiness handling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023319#comment-13023319 ] RH Bugzilla Integration commented on WFCORE-259: ------------------------------------------------ Ondrej Lukas changed the Status of [bug 1161668|https://bugzilla.redhat.com/show_bug.cgi?id=1161668] from ON_QA to VERIFIED > Improve realm readiness handling > -------------------------------- > > Key: WFCORE-259 > URL: https://issues.jboss.org/browse/WFCORE-259 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > Currently we display an error message informing users that they need to add a new user if any of the authentication mechanisms within a realm report that they are not ready to handle requests. > The reason for this was so that if properties backed authentication we available along with local authentication then the local authentication would not prevent the prompt from being displayed. > However there could be additional mechanisms suitable for use with HTTP so we need a small modification to stop taking into account the local authentication mechanism but allow requests in if any of the other HTTP compatible mechanisms are ready to handle requests. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 09:56:39 2014 From: issues at jboss.org (Peter Skopek (JIRA)) Date: Wed, 26 Nov 2014 09:56:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (ELY-42) Vault In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/ELY-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Skopek reassigned ELY-42: ------------------------------- Assignee: Peter Skopek > Vault > ----- > > Key: ELY-42 > URL: https://issues.jboss.org/browse/ELY-42 > Project: WildFly Elytron > Issue Type: Feature Request > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Fix For: 1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 10:12:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 10:12:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023322#comment-13023322 ] RH Bugzilla Integration commented on WFLY-4054: ----------------------------------------------- Kabir Khan changed the Status of [bug 1156032|https://bugzilla.redhat.com/show_bug.cgi?id=1156032] from MODIFIED to ASSIGNED > Unexpected attribute can be added to elements in Transactions Subsystem > ----------------------------------------------------------------------- > > Key: WFLY-4054 > URL: https://issues.jboss.org/browse/WFLY-4054 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. > When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 10:30:39 2014 From: issues at jboss.org (Chezy Palani (JIRA)) Date: Wed, 26 Nov 2014 10:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023335#comment-13023335 ] Chezy Palani commented on WFLY-4126: ------------------------------------ This is the other part of stack from the log file: Caused by: java.lang.ExceptionInInitializerError at org.apache.jasper.el.ELContextImpl.(ELContextImpl.java:72) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Validator$ValidateVisitor.checkXmlAttributes(Validator.java:1188) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Validator$ValidateVisitor.visit(Validator.java:844) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1530) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2427) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2433) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$Root.accept(Node.java:495) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2377) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Validator.validateExDirectives(Validator.java:1768) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:211) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Compiler.compile(Compiler.java:359) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Compiler.compile(Compiler.java:339) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.compiler.Compiler.compile(Compiler.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:604) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:309) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final] at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.Final.jar:1.0.0.Final] ... 42 more Caused by: java.lang.NullPointerException at javax.el.CompositeELResolver.add(CompositeELResolver.java:117) [jboss-el-api_3.0_spec-1.0.3.Final.jar:1.0.3.Final] at org.apache.jasper.el.ELResolverImpl.(ELResolverImpl.java:51) [jastow-1.0.0.Final.jar:1.0.0.Final] ... 60 more > java.lang.ExceptionInInitializerError when invoking BIRT service > ---------------------------------------------------------------- > > Key: WFLY-4126 > URL: https://issues.jboss.org/browse/WFLY-4126 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Windows 7 and JDK 1.8 > Reporter: Chezy Palani > Assignee: Stuart Douglas > > There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception. > Context Path: > /actuatejavacomponent > Servlet Path: > /iv > Path Info: > null > Query String: > __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US > Stack Trace > javax.servlet.ServletException: java.lang.ExceptionInInitializerError > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198) > io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279) > com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261) > com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144) > com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261) > javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 11:05:39 2014 From: issues at jboss.org (Fernando Nasser (JIRA)) Date: Wed, 26 Nov 2014 11:05:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4128) Move JAX-RS 2.0 API into JBoss Specs In-Reply-To: References: Message-ID: Fernando Nasser created WFLY-4128: ------------------------------------- Summary: Move JAX-RS 2.0 API into JBoss Specs Key: WFLY-4128 URL: https://issues.jboss.org/browse/WFLY-4128 Project: WildFly Issue Type: Task Components: REST Affects Versions: 9.0.0.Beta1 Reporter: Fernando Nasser Assignee: Tomaz Cerar Priority: Minor Currently the JAX-RS 2.0 API comes from the RESTEasy project but we should have a JBoss Spec JAX-RS 2.0 API and use that one instead. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 11:06:40 2014 From: issues at jboss.org (Tomaz Cerar (JIRA)) Date: Wed, 26 Nov 2014 11:06:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4128) Move JAX-RS 2.0 API into JBoss Specs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomaz Cerar updated WFLY-4128: ------------------------------ Affects Version/s: 8.2.0.Final (was: 9.0.0.Beta1) > Move JAX-RS 2.0 API into JBoss Specs > ------------------------------------ > > Key: WFLY-4128 > URL: https://issues.jboss.org/browse/WFLY-4128 > Project: WildFly > Issue Type: Task > Components: REST > Affects Versions: 8.2.0.Final > Reporter: Fernando Nasser > Assignee: Tomaz Cerar > Priority: Minor > > Currently the JAX-RS 2.0 API comes from the RESTEasy project but we should have a JBoss Spec JAX-RS 2.0 API and use that one instead. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 11:45:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 11:45:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1899) Discovery returns after 16 responses even if there are no coord responses In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated JGRP-1899: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1168329 > Discovery returns after 16 responses even if there are no coord responses > ------------------------------------------------------------------------- > > Key: JGRP-1899 > URL: https://issues.jboss.org/browse/JGRP-1899 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.2, 3.6.1 > > > Discovery sets {{Responses.num_expected_rsps}} to 16 if no member list is defined. This makes discovery return after 16 responses even if no response from a coordinator has been received. > This is a problem if we have a cluster of size > 16 and the coordinator doesn't respond imediately, e.g. because it is busy processing other requests. > h5. Solution > * Set {{num_expected_rsps}} to 0 (= wait until at least 1 coord rsp has been received -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 12:01:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 12:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-283) SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023358#comment-13023358 ] RH Bugzilla Integration commented on WFCORE-283: ------------------------------------------------ Darran Lofthouse changed the Status of [bug 1168313|https://bugzilla.redhat.com/show_bug.cgi?id=1168313] from ASSIGNED to POST > SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting > ------------------------------------------------------------------------------ > > Key: WFCORE-283 > URL: https://issues.jboss.org/browse/WFCORE-283 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting, Security > Affects Versions: 1.0.0.Alpha13 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 12:37:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 26 Nov 2014 12:37:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4129) The RemotingLoginModule should first check if there is already a RealmUser In-Reply-To: References: Message-ID: Darran Lofthouse created WFLY-4129: -------------------------------------- Summary: The RemotingLoginModule should first check if there is already a RealmUser Key: WFLY-4129 URL: https://issues.jboss.org/browse/WFLY-4129 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 9.0.0.Alpha1 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 9.0.0.Beta1 The reason is because the realm may have actually already substituted in a different name for the user. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 12:43:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 12:43:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4054) Unexpected attribute can be added to elements in Transactions Subsystem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023364#comment-13023364 ] RH Bugzilla Integration commented on WFLY-4054: ----------------------------------------------- Kabir Khan changed the Status of [bug 1156032|https://bugzilla.redhat.com/show_bug.cgi?id=1156032] from ASSIGNED to MODIFIED > Unexpected attribute can be added to elements in Transactions Subsystem > ----------------------------------------------------------------------- > > Key: WFLY-4054 > URL: https://issues.jboss.org/browse/WFLY-4054 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Amos Feng > Assignee: Amos Feng > > If you add unexpected argument to element in standalone.xml then it's expected to get error of "Unexpected attribute '...' encountered" [1] when server is started. > When you add a random argument to some of the elements in transactions then no error is thrown. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 12:43:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 12:43:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023365#comment-13023365 ] RH Bugzilla Integration commented on WFCORE-242: ------------------------------------------------ Kabir Khan changed the Status of [bug 1162444|https://bugzilla.redhat.com/show_bug.cgi?id=1162444] from POST to MODIFIED > the deployment content is deleted if first undeploy and then deploy the same application using CLI batch > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-242 > URL: https://issues.jboss.org/browse/WFCORE-242 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Domain Management > Reporter: Jay Kumar SenSharma > Assignee: Emmanuel Hugonnet > Priority: Minor > > - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error: > {code} > [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 12:58:39 2014 From: issues at jboss.org (Kyle Lape (JIRA)) Date: Wed, 26 Nov 2014 12:58:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4013) The value of the bound attribute in socket-binding-group messaging is always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kyle Lape updated WFLY-4013: ---------------------------- Forum Reference: (was: https://c.na7.visual.force.com/apex/Case_View?sbstr=01264236) > The value of the bound attribute in socket-binding-group messaging is always false > ---------------------------------------------------------------------------------- > > Key: WFLY-4013 > URL: https://issues.jboss.org/browse/WFLY-4013 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss EAP 6.3.1. > Reporter: Tom Ross > Assignee: Jeff Mesnil > > The value of bound attribute in messaging socket group is always false. > {noformat} > /socket-binding-group=standard-sockets/socket-binding=messaging:read-resource(include-runtime=true, recursive=true) > { > "outcome" => "success", > "result" => { > "bound" => false, > "bound-address" => undefined, > "bound-port" => undefined, > "client-mappings" => undefined, > "fixed-port" => false, > "interface" => undefined, > "multicast-address" => undefined, > "multicast-port" => undefined, > "name" => "messaging", > "port" => 5445 > } > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 13:06:39 2014 From: issues at jboss.org (Darran Lofthouse (JIRA)) Date: Wed, 26 Nov 2014 13:06:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-286) The SecurityRealmService should only perform a generic mapping to RealmUser if really required. In-Reply-To: References: Message-ID: Darran Lofthouse created WFCORE-286: --------------------------------------- Summary: The SecurityRealmService should only perform a generic mapping to RealmUser if really required. Key: WFCORE-286 URL: https://issues.jboss.org/browse/WFCORE-286 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 1.0.0.Alpha13 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Alpha14 If there is a more accurate way to calculate the RealmUser then use it. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 13:17:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Wed, 26 Nov 2014 13:17:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Fusco reassigned DROOLS-654: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config > ---------------------------------------------------------------------------------------------------- > > Key: DROOLS-654 > URL: https://issues.jboss.org/browse/DROOLS-654 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: Ubuntu Linux > Reporter: Tihomir Me??i? > Assignee: Mario Fusco > Priority: Blocker > > I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: > {{KieBaseConfiguration config = KieServices.Factory.get()}} > {{.newKieBaseConfiguration();}} > {{config.setOption(EventProcessingOption.STREAM);}} > > {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} > {{KieSession ksession = kc.newKieBase(config).newKieSession();}} > After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): > {{kc.updateToVersion( ... newReleaseId... );}} > It seems like all of the facts are removed from the session, and my rules are no longer triggered. > When I do not use the configuration object when creating the session and just use: > {{KieSession ksession = kc.newKieSession();}} > then, everything works as expected. However, this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 13:32:39 2014 From: issues at jboss.org (Scott Marlow (JIRA)) Date: Wed, 26 Nov 2014 13:32:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4130) check for -secmgr in appclient In-Reply-To: References: Message-ID: Scott Marlow created WFLY-4130: ---------------------------------- Summary: check for -secmgr in appclient Key: WFLY-4130 URL: https://issues.jboss.org/browse/WFLY-4130 Project: WildFly Issue Type: Feature Request Components: Application Client, Security Manager Reporter: Scott Marlow Assignee: James Perkins Fix For: 9.0.0.Beta1 We are currently getting a TCK failure due to the security manager not being enabled in our application client container. We can pass the -secmgr option if that could be handled in the app container. Current TCK error (in ejb30/sec/permsxml: {quote} ERROR: Security Manager is NOT enabled and must be for these tests. If you have passed these tests while running with Security Manager enabled, you can use keywords to bypass the running of these tests when Security Manager is disabled. {quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 13:35:39 2014 From: issues at jboss.org (Sebastien Chassande (JIRA)) Date: Wed, 26 Nov 2014 13:35:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-657) Salience ignored when no-loop set In-Reply-To: References: Message-ID: Sebastien Chassande created DROOLS-657: ------------------------------------------ Summary: Salience ignored when no-loop set Key: DROOLS-657 URL: https://issues.jboss.org/browse/DROOLS-657 Project: Drools Issue Type: Bug Affects Versions: 6.1.0.Final Environment: Windows x64, java 7, eclipse Reporter: Sebastien Chassande Assignee: Mark Proctor Priority: Blocker Hello, When we define the no-loop attribute on rules the salience is ignored. The rule execution order is the declaration order. Best regards, Seb -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 13:39:39 2014 From: issues at jboss.org (Sebastien Chassande (JIRA)) Date: Wed, 26 Nov 2014 13:39:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-657) Salience ignored when no-loop set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023374#comment-13023374 ] Sebastien Chassande commented on DROOLS-657: -------------------------------------------- You can download from my dropbox a simple Java/Eclipse/Maven project showing the bug : https://www.dropbox.com/s/7j8w7ejehe140td/saliencebug_projet.zip?dl=0 > Salience ignored when no-loop set > --------------------------------- > > Key: DROOLS-657 > URL: https://issues.jboss.org/browse/DROOLS-657 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Environment: Windows x64, java 7, eclipse > Reporter: Sebastien Chassande > Assignee: Mark Proctor > Priority: Blocker > Labels: no-loop, salience > > Hello, > When we define the no-loop attribute on rules the salience is ignored. The rule execution order is the declaration order. > Best regards, > Seb -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 13:43:39 2014 From: issues at jboss.org (=?UTF-8?Q?Tihomir_Me=C5=A1=C4=8Di=C4=87_=28JIRA=29?=) Date: Wed, 26 Nov 2014 13:43:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023375#comment-13023375 ] Tihomir Me??i? commented on DROOLS-654: --------------------------------------- Thanks for clearing this up, but, is there another way to: 1. use Drools in Stream mode (I use window:time, so I need this), and 2. have the ability to update rules in runtime ? > Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config > ---------------------------------------------------------------------------------------------------- > > Key: DROOLS-654 > URL: https://issues.jboss.org/browse/DROOLS-654 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: Ubuntu Linux > Reporter: Tihomir Me??i? > Assignee: Mario Fusco > Priority: Blocker > > I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: > {{KieBaseConfiguration config = KieServices.Factory.get()}} > {{.newKieBaseConfiguration();}} > {{config.setOption(EventProcessingOption.STREAM);}} > > {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} > {{KieSession ksession = kc.newKieBase(config).newKieSession();}} > After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): > {{kc.updateToVersion( ... newReleaseId... );}} > It seems like all of the facts are removed from the session, and my rules are no longer triggered. > When I do not use the configuration object when creating the session and just use: > {{KieSession ksession = kc.newKieSession();}} > then, everything works as expected. However, this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 13:48:39 2014 From: issues at jboss.org (Mario Fusco (JIRA)) Date: Wed, 26 Nov 2014 13:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023376#comment-13023376 ] Mario Fusco commented on DROOLS-654: ------------------------------------ Yes, sorry I forgot to mention this. You can write this declaratively in the kmodule.xml file of your kproject. if you want you can also generate the kmodule.xml file programmatically and add it to the KieFileSystem, see an example here: https://github.com/droolsjbpm/drools/blob/master/kie-ci/src/test/java/org/kie/scanner/AbstractKieCiTest.java#L78 > Dynamic update with KieContainer.updateToVersion() not working when ksession was created with config > ---------------------------------------------------------------------------------------------------- > > Key: DROOLS-654 > URL: https://issues.jboss.org/browse/DROOLS-654 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: Ubuntu Linux > Reporter: Tihomir Me??i? > Assignee: Mario Fusco > Priority: Blocker > > I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration: > {{KieBaseConfiguration config = KieServices.Factory.get()}} > {{.newKieBaseConfiguration();}} > {{config.setOption(EventProcessingOption.STREAM);}} > > {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}} > {{KieSession ksession = kc.newKieBase(config).newKieSession();}} > After that, everything works fine. But when I try to dynamically update to a new version (containing new rules): > {{kc.updateToVersion( ... newReleaseId... );}} > It seems like all of the facts are removed from the session, and my rules are no longer triggered. > When I do not use the configuration object when creating the session and just use: > {{KieSession ksession = kc.newKieSession();}} > then, everything works as expected. However, this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of). -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 14:09:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 14:09:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-57) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023379#comment-13023379 ] RH Bugzilla Integration commented on WFCORE-57: ----------------------------------------------- Emmanuel Hugonnet (ehsavoie) changed the Status of [bug 1070214|https://bugzilla.redhat.com/show_bug.cgi?id=1070214] from ON_QA to POST > Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* > -------------------------------------------------------------------------------- > > Key: WFCORE-57 > URL: https://issues.jboss.org/browse/WFCORE-57 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Harald Pehl > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > When executing > {code} > /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2) > {code} > the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}: > {code} > ... > "acl" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > "model-description" => {"classic" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > ... > "operations" => undefined, > "children" => { > "acl-module" => { > "description" => "ACL module", > "model-description" => {"*" => { > "description" => "List of authentication modules", > ... > "operations" => undefined, > "children" => {} > }} > }, > "login-module" => { > "description" => "Login module", > "model-description" => {"*" => undefined} > } > } > }} > }, > ... > {code} > However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 15:08:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 26 Nov 2014 15:08:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023396#comment-13023396 ] RH Bugzilla Integration commented on JGRP-1898: ----------------------------------------------- Dave Stahl changed the Status of [bug 1159162|https://bugzilla.redhat.com/show_bug.cgi?id=1159162] from MODIFIED to ON_QA > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 18:30:39 2014 From: issues at jboss.org (arjan tijms (JIRA)) Date: Wed, 26 Nov 2014 18:30:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3518) JASPIAuthenticationMechanism#authenticate doesn't check if AuthenticatedSession is null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023412#comment-13023412 ] arjan tijms commented on WFLY-3518: ----------------------------------- Just wondering if there's any update for this issue. We've been using the extra null check in production since June. At least for our use case we didn't see any side-effects. > JASPIAuthenticationMechanism#authenticate doesn't check if AuthenticatedSession is null > --------------------------------------------------------------------------------------- > > Key: WFLY-3518 > URL: https://issues.jboss.org/browse/WFLY-3518 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 8.1.0.Final > Reporter: arjan tijms > Assignee: Darran Lofthouse > Labels: jaspic > > In {{org.wildfly.extension.undertow.security.jaspi.JASPIAuthenticationMechanism#authenticate}} the variable {{authSession}} in the fragment below is frequently null, leading to null pointer exceptions: > {code} > if (sessionManager != null) { > AuthenticatedSessionManager.AuthenticatedSession authSession = sessionManager.lookupSession(exchange); > cachedAccount = authSession.getAccount(); // NPE HAPPENS HERE > // if there is a cached account we set it in the security context so that the principal is available to > // SAM modules via request.getUserPrincipal(). > if (cachedAccount != null) { > jaspicSecurityContext.setCachedAuthenticatedAccount(cachedAccount); > } > } > {code} > At another place in Undertow where {{AuthenticatedSession}} is used, there's an extra null check (See {{io.undertow.security.impl.CachedAuthenticatedSessionMechanism#runCached}}). > I patched the code locally to add an extra null check: > {code} > if (sessionManager != null) { > AuthenticatedSessionManager.AuthenticatedSession authSession = sessionManager.lookupSession(exchange); > cachedAccount = authSession == null? null : authSession.getAccount(); > // if there is a cached account we set it in the security context so that the principal is available to > // SAM modules via request.getUserPrincipal(). > if (cachedAccount != null) { > jaspicSecurityContext.setCachedAuthenticatedAccount(cachedAccount); > } > } > {code} > After a short amount of testing everything seems to be okay with that extra check. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Wed Nov 26 20:27:39 2014 From: issues at jboss.org (Stuart Douglas (JIRA)) Date: Wed, 26 Nov 2014 20:27:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023418#comment-13023418 ] Stuart Douglas commented on WFLY-4126: -------------------------------------- Are there any other exceptions earlier in the log? Looking at the code it does not seem obvious how this could be null. > java.lang.ExceptionInInitializerError when invoking BIRT service > ---------------------------------------------------------------- > > Key: WFLY-4126 > URL: https://issues.jboss.org/browse/WFLY-4126 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: Windows 7 and JDK 1.8 > Reporter: Chezy Palani > Assignee: Stuart Douglas > > There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception. > Context Path: > /actuatejavacomponent > Servlet Path: > /iv > Path Info: > null > Query String: > __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US > Stack Trace > javax.servlet.ServletException: java.lang.ExceptionInInitializerError > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198) > io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279) > com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261) > com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144) > com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261) > javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) > io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 02:16:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 02:16:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-1631) Duplicated message ids in web, undertow, jsf and osgi subsystems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023425#comment-13023425 ] RH Bugzilla Integration commented on WFLY-1631: ----------------------------------------------- Nikoleta Ziakova changed the Status of [bug 980823|https://bugzilla.redhat.com/show_bug.cgi?id=980823] from ON_QA to VERIFIED > Duplicated message ids in web, undertow, jsf and osgi subsystems > ----------------------------------------------------------------- > > Key: WFLY-1631 > URL: https://issues.jboss.org/browse/WFLY-1631 > Project: WildFly > Issue Type: Bug > Components: JSF, OSGi, Web (Undertow) > Affects Versions: 8.0.0.Alpha2 > Reporter: Ivo Studensky > Assignee: Tomaz Cerar > Priority: Critical > Fix For: 8.0.0.CR1 > > > There is a lot of duplicated or different messages in JBossWeb and Undertow subsystems which has the same ids. > different messages: > {noformat} > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12604, value = "JSF version slot '%s' is missing from module %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12604, value = "WildFlyConversationAwareViewHandler was improperly initialized. Expected ViewHandler parent.") > {noformat} > duplicated messages with the same content: > {noformat} > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12600, value = "Could not load JSF managed bean class: %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12600, value = "Could not load JSF managed bean class: %s") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12601, value = "JSF managed bean class %s has no default constructor") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12601, value = "JSF managed bean class %s has no default constructor") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12602, value = "Failed to parse %s, managed beans defined in this file will not be available") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12602, value = "Failed to parse %s, managed beans defined in this file will not be available") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12603, value = "Unknown JSF version '%s'. Default version '%s' will be used instead.") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFLogger.java: @Message(id = 12603, value = "Unknown JSF version %s %s will be used instead") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12650, value = "Failed to load annotated class: %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12650, value = "Failed to load annotated class: %s") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12651, value = "Annotation %s in class %s is only allowed on classes") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12651, value = "Annotation %s in class %s is only allowed on classes") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12652, value = "Instance creation failed") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12652, value = "Instance creation failed") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12653, value = "Instance destruction failed") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12653, value = "Instance destruction failed") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12654, value = "Thread local injection container not set") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12654, value = "Thread local injection container not set") > jsf/subsystem/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12655, value = "@ManagedBean is only allowed at class level %s") > jsf/injection/src/main/java/org/jboss/as/jsf/JSFMessages.java: @Message(id = 12655, value = "@ManagedBean is only allowed at class level %s") > web/src/main/java/org/jboss/as/web/WebMessages.java: @Message(id = 18039, value = "Failed to create context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18039, value = "Failed to create context") > web/src/main/java/org/jboss/as/web/WebMessages.java: @Message(id = 18040, value = "Failed to start context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18040, value = "Failed to start context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18200, value = "Failed to start welcome context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18200, value = "Failed to start welcome context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18201, value = "Failed to destroy welcome context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18201, value = "Failed to destroy welcome context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18202, value = "Error calling onStartup for servlet container initializer: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18202, value = "Error calling onStartup for servlet container initializer: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18203, value = "Error instantiating container component: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18203, value = "Error instantiating container component: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18204, value = "Clustering not supported, falling back to non-clustered session manager") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18204, value = "Clustering not supported, falling back to non-clustered session manager") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18205, value = "Cannot setup overlays for [%s] due to custom resources") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18205, value = "Cannot setup overlays for [%s] due to custom resources") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18206, value = "Webapp [%s] is unavailable due to startup errors") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18206, value = "Webapp [%s] is unavailable due to startup errors") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18208, value = "Failed to start context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18208, value = "Failed to start context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18208, value = "Failed to start context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18209, value = "Failed to destroy context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18209, value = "Failed to destroy context") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18209, value = "Failed to destroy context") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18210, value = "Register web context: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18210, value = "Register web context: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > osgi/integration/http/src/main/java/org/jboss/as/osgi/httpservice/WebLogger.java: @Message(id = 18210, value = "Register web context: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18214, value = "Error during login/password authenticate") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18214, value = "Error during login/password authenticate") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18215, value = "Error during certificate authenticate") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18215, value = "Error during certificate authenticate") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18216, value = "Error during digest authenticate") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18216, value = "Error during digest authenticate") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18217, value = "Error obtaining authorization helper") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18217, value = "Error obtaining authorization helper") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18218, value = "Exception in obtaining server authentication manager") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18218, value = "Exception in obtaining server authentication manager") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18219, value = "JASPI validation for unprotected request context %s failed") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18219, value = "JASPI validation for unprotected request context %s failed") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18220, value = "Caught Exception: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18220, value = "Caught Exception: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18221, value = "Error forwarding to login page: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18221, value = "Error forwarding to login page: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18222, value = "Error forwarding to error page: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18222, value = "Error forwarding to error page: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18224, value = "Unregister web context: %s") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18224, value = "Unregister web context: %s") > undertow/src/main/java/org/wildfly/extension/undertow/UndertowLogger.java: @Message(id = 18226, value = "Skipped SCI for jar: %s.") > web/src/main/java/org/jboss/as/web/WebLogger.java: @Message(id = 18226, value = "Skipped SCI for jar: %s.") > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 03:17:39 2014 From: issues at jboss.org (Sebastien Chassande (JIRA)) Date: Thu, 27 Nov 2014 03:17:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-657) Salience ignored when no-loop set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastien Chassande closed DROOLS-657. -------------------------------------- Resolution: Cannot Reproduce Bug All is ok. To show the execution order of the rule we used a listener of matchCreated event. That's our mistake. > Salience ignored when no-loop set > --------------------------------- > > Key: DROOLS-657 > URL: https://issues.jboss.org/browse/DROOLS-657 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Environment: Windows x64, java 7, eclipse > Reporter: Sebastien Chassande > Assignee: Mark Proctor > Priority: Blocker > Labels: no-loop, salience > > Hello, > When we define the no-loop attribute on rules the salience is ignored. The rule execution order is the declaration order. > Best regards, > Seb -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 03:28:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 03:28:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4110) EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023439#comment-13023439 ] RH Bugzilla Integration commented on WFLY-4110: ----------------------------------------------- Petr Kremensky changed the Status of [bug 1164231|https://bugzilla.redhat.com/show_bug.cgi?id=1164231] from ON_QA to VERIFIED > EJBClientClusterConfigurationTestCase fails on JDK1.8 once -Dnode0 and -Dnode1 are used > --------------------------------------------------------------------------------------- > > Key: WFLY-4110 > URL: https://issues.jboss.org/browse/WFLY-4110 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: Dominik Pospisil > Assignee: Dominik Pospisil > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 04:55:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 04:55:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (SECURITY-733) Session replication broken by NegotiationAuthenticator valve In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SECURITY-733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023473#comment-13023473 ] RH Bugzilla Integration commented on SECURITY-733: -------------------------------------------------- Josef Cacek changed the Status of [bug 949737|https://bugzilla.redhat.com/show_bug.cgi?id=949737] from ON_QA to VERIFIED > Session replication broken by NegotiationAuthenticator valve > ------------------------------------------------------------ > > Key: SECURITY-733 > URL: https://issues.jboss.org/browse/SECURITY-733 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_2_2_2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_3 > > > From an initial review of the code I believe this is because the ClusterSessionValve implements the Listener interface - however the wrapper class does not. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 05:19:39 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Thu, 27 Nov 2014 05:19:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-199) The entire kie 6.3 build should move maven from 3.0.5 to 3.2.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023497#comment-13023497 ] Michael Biarnes Kiefer commented on DROOLS-199: ----------------------------------------------- did a mvn clean install -Dfull -DskipTests with apache_maven_3.2.3 and droolsjbpm-tools did not build: https://gist.github.com/mbiarnes/32f48e28aed298a35dcf repeated a mvn clean install -Dfull -DskipTests with apache_maven_3.0.5 and it worked. there is something with the tycho plugin. > The entire kie 6.3 build should move maven from 3.0.5 to 3.2.x > -------------------------------------------------------------- > > Key: DROOLS-199 > URL: https://issues.jboss.org/browse/DROOLS-199 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > Old description: > To reproduce: > - Install maven 3.1.0 > - Run mvn-all.sh clean install -Dfull > Note: Any changes to the pom must still allow them to run with 3.0.5 too. > 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. > So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). > 2) There might be other surprises... -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 05:56:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 05:56:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4129) The RemotingLoginModule should first check if there is already a RealmUser In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4129: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1168585 > The RemotingLoginModule should first check if there is already a RealmUser > -------------------------------------------------------------------------- > > Key: WFLY-4129 > URL: https://issues.jboss.org/browse/WFLY-4129 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > The reason is because the realm may have actually already substituted in a different name for the user. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 06:06:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 06:06:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-160) Bash scripts should not attempt to expand argument properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023512#comment-13023512 ] RH Bugzilla Integration commented on WFCORE-160: ------------------------------------------------ Petr Kremensky changed the Status of [bug 1145960|https://bugzilla.redhat.com/show_bug.cgi?id=1145960] from ON_QA to VERIFIED > Bash scripts should not attempt to expand argument properties > ------------------------------------------------------------- > > Key: WFCORE-160 > URL: https://issues.jboss.org/browse/WFCORE-160 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.0.0.Alpha10 > > > Scripts that parse the command line arguments use a pattern like > {code} > while [ "$#" -gt 0 ] > do > case "$1" in > *) > CLI_OPTS="$CLI_OPTS \"$1\"" > ;; > esac > shift > done > {code} > The {{CLI_OPTS="$CLI_OPTS \"$1\""}} should be {{CLI_OPTS="$CLI_OPTS '$1'"}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 06:18:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 06:18:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4129) The RemotingLoginModule should first check if there is already a RealmUser In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023515#comment-13023515 ] RH Bugzilla Integration commented on WFLY-4129: ----------------------------------------------- Darran Lofthouse changed the Status of [bug 1168585|https://bugzilla.redhat.com/show_bug.cgi?id=1168585] from ASSIGNED to POST > The RemotingLoginModule should first check if there is already a RealmUser > -------------------------------------------------------------------------- > > Key: WFLY-4129 > URL: https://issues.jboss.org/browse/WFLY-4129 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > The reason is because the realm may have actually already substituted in a different name for the user. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 06:22:39 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Thu, 27 Nov 2014 06:22:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4131) TransportConfiguration does not check the name in equals In-Reply-To: References: Message-ID: Jeff Mesnil created WFLY-4131: --------------------------------- Summary: TransportConfiguration does not check the name in equals Key: WFLY-4131 URL: https://issues.jboss.org/browse/WFLY-4131 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 8.1.0.Final Environment: Windows 7 Pro, Java 7u55 Reporter: Jeff Mesnil Assignee: Jeff Mesnil With both an http-acceptor and an https-acceptor configured in the message subsystem, when an external Java app attempts to connect, it times out and the exception below appears in the server log. I tracked it down to the TransportConfigOperationHandlers.processAcceptors() method. At the end of the method, it creates a HashSet of the TransportConfiguration objects representing the acceptors. But, the TransportConfiguration equals() method reports that the https and http acceptors are equal, and as it is building a Set of unique values, the https-acceptor gets dropped. Later, when the http-upgrade handshake runs, the code is unable to find the https-acceptor, resulting in the NullPointerException. I think the fix might be to either not use a Set, or to look at the TransportConfiguration.equals() method. The workaround in the ticket works because the redundant causes the equals() method to see the two acceptors as unequal. The exception was: [exec] 10:07:57,502 ERROR [org.xnio.listener] (default I/O-10) XNIO001007: A channel event listener threw an exception: java.lang.NullPointerException [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:161) [exec] at org.jboss.as.messaging.HTTPUpgradeService$2.handleEvent(HTTPUpgradeService.java:153) [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final] [exec] at io.undertow.server.handlers.ChannelUpgradeHandler$1.handleUpgrade(ChannelUpgradeHandler.java:149) [exec] at io.undertow.server.protocol.http.HttpReadListener.exchangeComplete(HttpReadListener.java:271) [exec] at io.undertow.server.protocol.http.HttpServerConnection.exchangeComplete(HttpServerConnection.java:221) [exec] at io.undertow.server.HttpServerExchange.invokeExchangeCompleteListeners(HttpServerExchange.java:1131) [exec] at io.undertow.server.HttpServerExchange.terminateResponse(HttpServerExchange.java:1351) [exec] at io.undertow.server.Connectors.terminateResponse(Connectors.java:78) [exec] at io.undertow.server.protocol.http.ServerFixedLengthStreamSinkConduit.channelFinished(ServerFixedLengthStreamSinkConduit.java:33) [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.exitFlush(AbstractFixedLengthStreamSinkConduit.java:273) [exec] at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.flush(AbstractFixedLengthStreamSinkConduit.java:207) [exec] at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162) [xnio-api-3.2.2.Final.jar:3.2.2.Final] [exec] at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100) [exec] at io.undertow.server.HttpServerExchange.closeAndFlushResponse(HttpServerExchange.java:1489) [exec] at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1470) [exec] at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:152) [exec] at io.undertow.server.handlers.ProxyPeerAddressHandler.handleRequest(ProxyPeerAddressHandler.java:45) [exec] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:156) [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:91) [exec] at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:45) [exec] at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.2.2.Final.jar:3.2.2.Final] [exec] at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.2.2.Final.jar:3.2.2.Final] [exec] at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) [xnio-nio-3.2.2.Final.jar:3.2.2.Final] [exec] at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) [xnio-nio-3.2.2.Final.jar:3.2.2.Final] -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 06:24:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 06:24:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-286) The SecurityRealmService should only perform a generic mapping to RealmUser if really required. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFCORE-286: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1168595 > The SecurityRealmService should only perform a generic mapping to RealmUser if really required. > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-286 > URL: https://issues.jboss.org/browse/WFCORE-286 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > If there is a more accurate way to calculate the RealmUser then use it. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 06:55:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 06:55:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-195) Outbound LDAP connection in domain mode test case In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023540#comment-13023540 ] RH Bugzilla Integration commented on WFCORE-195: ------------------------------------------------ Hynek Mlnarik changed the Status of [bug 1148400|https://bugzilla.redhat.com/show_bug.cgi?id=1148400] from ON_QA to VERIFIED > Outbound LDAP connection in domain mode test case > ------------------------------------------------- > > Key: WFCORE-195 > URL: https://issues.jboss.org/browse/WFCORE-195 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security, Test Suite > Affects Versions: 1.0.0.Alpha11 > Reporter: Ondrej Kotek > Assignee: Ondrej Kotek > Fix For: 1.0.0.Alpha11 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 07:16:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 07:16:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-286) The SecurityRealmService should only perform a generic mapping to RealmUser if really required. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023547#comment-13023547 ] RH Bugzilla Integration commented on WFCORE-286: ------------------------------------------------ Darran Lofthouse changed the Status of [bug 1168595|https://bugzilla.redhat.com/show_bug.cgi?id=1168595] from ASSIGNED to POST > The SecurityRealmService should only perform a generic mapping to RealmUser if really required. > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-286 > URL: https://issues.jboss.org/browse/WFCORE-286 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > If there is a more accurate way to calculate the RealmUser then use it. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 07:47:39 2014 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 27 Nov 2014 07:47:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4132) Transaction subsystem does not initialise the recovery store correctly In-Reply-To: References: Message-ID: Michael Musgrove created WFLY-4132: -------------------------------------- Summary: Transaction subsystem does not initialise the recovery store correctly Key: WFLY-4132 URL: https://issues.jboss.org/browse/WFLY-4132 Project: WildFly Issue Type: Bug Components: Transactions Affects Versions: 9.0.0.Alpha1 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 9.0.0.Beta1 The initialisation code in the transaction subsystem sets the transaction log directory on the wrong instance (https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/service/ArjunaObjectStoreEnvironmentService.java#L78). The code should pass in the null string for the instance name to get the default instance. The bug arises because we recently fixed JBTM-2207 in order to avoid string comparison with the default name and the reason this is not a backwards compatibility issue is that com.arjuna.common.internal.util.propertyservice.BeanPopulator is internal code that the app server is using. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 08:20:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 08:20:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-283) SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023579#comment-13023579 ] RH Bugzilla Integration commented on WFCORE-283: ------------------------------------------------ Kabir Khan changed the Status of [bug 1168313|https://bugzilla.redhat.com/show_bug.cgi?id=1168313] from POST to MODIFIED > SASL_SERVER and SASL_PROTOCOL options not being passed all the way to Remoting > ------------------------------------------------------------------------------ > > Key: WFCORE-283 > URL: https://issues.jboss.org/browse/WFCORE-283 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting, Security > Affects Versions: 1.0.0.Alpha13 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 08:44:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 08:44:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-260) Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023597#comment-13023597 ] RH Bugzilla Integration commented on WFCORE-260: ------------------------------------------------ Ondrej Lukas changed the Status of [bug 1161589|https://bugzilla.redhat.com/show_bug.cgi?id=1161589] from ON_QA to ASSIGNED > Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab > ------------------------------------------------------------------------------------------ > > Key: WFCORE-260 > URL: https://issues.jboss.org/browse/WFCORE-260 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 08:55:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 08:55:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3285) Domain directory properties only work on specific operating systems In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023604#comment-13023604 ] RH Bugzilla Integration commented on WFLY-3285: ----------------------------------------------- Petr Kremensky changed the Status of [bug 1091198|https://bugzilla.redhat.com/show_bug.cgi?id=1091198] from ON_QA to ASSIGNED > Domain directory properties only work on specific operating systems > ------------------------------------------------------------------- > > Key: WFLY-3285 > URL: https://issues.jboss.org/browse/WFLY-3285 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 8.1.0.CR1 > Reporter: Dennis Reed > Assignee: Tomaz Cerar > > domain.sh only parses -Djboss.domain.base.dir, -Djboss.domain.log.dir, and -Djboss.domain.config.dir (used to set -Dlogging.configuration and -Dorg.jboss.boot.log.file) on Linux, Solaris, and OS X. > It does not attempt to parse these (and therefore does not set the logging properties correctly) on any other OS, including AIX. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 09:21:39 2014 From: issues at jboss.org (Tom Fonteyne (JIRA)) Date: Thu, 27 Nov 2014 09:21:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3688) datasources subsystem: datasource and xa-datasource properties do not support the use of multiple values for one property In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Fonteyne updated WFLY-3688: ------------------------------- Summary: datasources subsystem: datasource and xa-datasource properties do not support the use of multiple values for one property (was: datasources subsystem: xa-datasource properties doe not support the use of multiple values for one property) > datasources subsystem: datasource and xa-datasource properties do not support the use of multiple values for one property > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3688 > URL: https://issues.jboss.org/browse/WFLY-3688 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.1.0.Final > Reporter: Tom Fonteyne > Assignee: Stefano Maestri > > The oracle JDBC driver had a method: > setConnectionProperties(java.util.Properties value) > which is needed to set several connection properties for datasources. > Most (all?) of these connection properties do not have individual setters. > WildFly does not support setting a "Properties" value for "xa-datasource-property" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 09:22:39 2014 From: issues at jboss.org (Tom Fonteyne (JIRA)) Date: Thu, 27 Nov 2014 09:22:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3688) datasources subsystem: datasource and xa-datasource properties do not support the use of multiple values for one property In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Fonteyne updated WFLY-3688: ------------------------------- Steps to Reproduce: I logged this as a bug due to the fact we certify with the Oracle JDBC driver. It could be argued this is an RFE. I can see two solutions. 1. Limited to datasource and xa-datasource: org.jboss.as.connector.subsystems.datasources.DsParser.java -> schema change so a list of values can be assigned to a single xa-property, in JCA support a call to setXXX(java.util.Properties) 2. a universal fix to the ModelNode class to allow java.util.Properties was: I logged this as a bug due to the fact we certify with the Oracle JDBC driver. It could be argued this is an RFE. I can see two solutions. 1. Limited to xa-datasource: org.jboss.as.connector.subsystems.datasources.DsParser.java -> schema change so a list of values can be assigned to a single xa-property, in JCA support a call to setXXX(java.util.Properties) 2. a universal fix to the ModelNode class to allow java.util.Properties > datasources subsystem: datasource and xa-datasource properties do not support the use of multiple values for one property > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3688 > URL: https://issues.jboss.org/browse/WFLY-3688 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.1.0.Final > Reporter: Tom Fonteyne > Assignee: Stefano Maestri > > The oracle JDBC driver had a method: > setConnectionProperties(java.util.Properties value) > which is needed to set several connection properties for datasources. > Most (all?) of these connection properties do not have individual setters. > WildFly does not support setting a "Properties" value for "xa-datasource-property" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 09:22:39 2014 From: issues at jboss.org (Tom Fonteyne (JIRA)) Date: Thu, 27 Nov 2014 09:22:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3688) datasources subsystem: datasource and xa-datasource properties do not support the use of multiple values for one property In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Fonteyne updated WFLY-3688: ------------------------------- Description: The oracle JDBC driver had a method: setConnectionProperties(java.util.Properties value) which is needed to set several connection properties for datasources. Most (all?) of these connection properties do not have individual setters. WildFly does not support setting a "Properties" value for "datasource-property" was: The oracle JDBC driver had a method: setConnectionProperties(java.util.Properties value) which is needed to set several connection properties for datasources. Most (all?) of these connection properties do not have individual setters. WildFly does not support setting a "Properties" value for "xa-datasource-property" > datasources subsystem: datasource and xa-datasource properties do not support the use of multiple values for one property > ------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-3688 > URL: https://issues.jboss.org/browse/WFLY-3688 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.1.0.Final > Reporter: Tom Fonteyne > Assignee: Stefano Maestri > > The oracle JDBC driver had a method: > setConnectionProperties(java.util.Properties value) > which is needed to set several connection properties for datasources. > Most (all?) of these connection properties do not have individual setters. > WildFly does not support setting a "Properties" value for "datasource-property" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 09:42:40 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 27 Nov 2014 09:42:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3548) JTA synchronization for a distributed transaction called with incorrect TCCL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023617#comment-13023617 ] Martin Kouba commented on WFLY-3548: ------------------------------------ The {{NameNotFoundException}} is gone and the CDI TCK test is passing. Waiting for the verification of the second part of the issue (TCCL). > JTA synchronization for a distributed transaction called with incorrect TCCL > ---------------------------------------------------------------------------- > > Key: WFLY-3548 > URL: https://issues.jboss.org/browse/WFLY-3548 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.1.0.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > > It seems the RequestProcessor which is processing JTA synchronizations > does not have the right TCCL set. > As a result, during synchronization invocation: > * {{NameNotFoundException}} is thrown for a JNDI lookup of "java:comp/UserTransaction" > * if we try to acccess {{org.jboss.weld.Container}} by means of {{org.jboss.as.weld.services.ModuleGroupSingletonProvider.TCCLSingleton}}, we get ISE: "Singleton not set....This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment." -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 09:43:40 2014 From: issues at jboss.org (Martin Kouba (JIRA)) Date: Thu, 27 Nov 2014 09:43:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3548) JTA synchronization for a distributed transaction called with incorrect TCCL In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kouba updated WFLY-3548: ------------------------------- Fix Version/s: 9.0.0.Beta1 > JTA synchronization for a distributed transaction called with incorrect TCCL > ---------------------------------------------------------------------------- > > Key: WFLY-3548 > URL: https://issues.jboss.org/browse/WFLY-3548 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 8.1.0.Final > Reporter: Martin Kouba > Assignee: Martin Kouba > Fix For: 9.0.0.Beta1 > > > It seems the RequestProcessor which is processing JTA synchronizations > does not have the right TCCL set. > As a result, during synchronization invocation: > * {{NameNotFoundException}} is thrown for a JNDI lookup of "java:comp/UserTransaction" > * if we try to acccess {{org.jboss.weld.Container}} by means of {{org.jboss.as.weld.services.ModuleGroupSingletonProvider.TCCLSingleton}}, we get ISE: "Singleton not set....This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment." -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 09:46:39 2014 From: issues at jboss.org (Radim Vansa (JIRA)) Date: Thu, 27 Nov 2014 09:46:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radim Vansa updated JGRP-1898: ------------------------------ Attachment: FD_HOSTTest.java This unit test reproduces the issue (and verifies that it's fixed). > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: FD_HOSTTest.java, test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 09:47:39 2014 From: issues at jboss.org (Radim Vansa (JIRA)) Date: Thu, 27 Nov 2014 09:47:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023619#comment-13023619 ] Radim Vansa edited comment on JGRP-1898 at 11/27/14 9:46 AM: ------------------------------------------------------------- Attached unit test reproduces the issue (and verifies that it's fixed). was (Author: rvansa): This unit test reproduces the issue (and verifies that it's fixed). > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: FD_HOSTTest.java, test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 09:48:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 09:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (JGRP-1898) FD_HOST many false suspect with Full GC In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JGRP-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023620#comment-13023620 ] RH Bugzilla Integration commented on JGRP-1898: ----------------------------------------------- Radim Vansa changed the Status of [bug 1159162|https://bugzilla.redhat.com/show_bug.cgi?id=1159162] from ON_QA to VERIFIED > FD_HOST many false suspect with Full GC > --------------------------------------- > > Key: JGRP-1898 > URL: https://issues.jboss.org/browse/JGRP-1898 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.5.1 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > Fix For: 3.4.7, 3.5.2, 3.6.1 > > Attachments: FD_HOSTTest.java, test-fdhost.zip > > > Currently FD_HOST PingTask has 2 loops, ping loop and cheking timeout loop. > {code} > for (h: hosts) { ping_and_update_timestamp(host) } > current = System.currentTimeMillis(); > for (h: hosts) { compare current and (ping_timestmp + timeout) } > {code} > Testing with large number of hosts, after lengthy Full GC during the ping loop, FD_HOST checks timeout and it counts the Full GC time in, sometimes causes many false suspects. > For example, 1 min Full GC and 50 sec timeout, all hosts are suspected with current implementation. > To reduce the impact of the Full GC time, we can combine the 2 loops into 1 loop, ping and checking timeout each host, so the Full GC delay only affects to a single host and never affect to other hosts. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 10:15:40 2014 From: issues at jboss.org (Jeff Mesnil (JIRA)) Date: Thu, 27 Nov 2014 10:15:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4013) The value of the bound attribute in socket-binding-group messaging is always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Mesnil updated WFLY-4013: ------------------------------ Fix Version/s: 9.0.0.Beta1 > The value of the bound attribute in socket-binding-group messaging is always false > ---------------------------------------------------------------------------------- > > Key: WFLY-4013 > URL: https://issues.jboss.org/browse/WFLY-4013 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss EAP 6.3.1. > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > The value of bound attribute in messaging socket group is always false. > {noformat} > /socket-binding-group=standard-sockets/socket-binding=messaging:read-resource(include-runtime=true, recursive=true) > { > "outcome" => "success", > "result" => { > "bound" => false, > "bound-address" => undefined, > "bound-port" => undefined, > "client-mappings" => undefined, > "fixed-port" => false, > "interface" => undefined, > "multicast-address" => undefined, > "multicast-port" => undefined, > "name" => "messaging", > "port" => 5445 > } > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 10:48:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 10:48:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-260) Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023646#comment-13023646 ] RH Bugzilla Integration commented on WFCORE-260: ------------------------------------------------ Darran Lofthouse changed the Status of [bug 1161589|https://bugzilla.redhat.com/show_bug.cgi?id=1161589] from ASSIGNED to POST > Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab > ------------------------------------------------------------------------------------------ > > Key: WFCORE-260 > URL: https://issues.jboss.org/browse/WFCORE-260 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 10:51:39 2014 From: issues at jboss.org (Geoffrey De Smet (JIRA)) Date: Thu, 27 Nov 2014 10:51:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-656) The blessed repo's should not accept a git force push In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023649#comment-13023649 ] Geoffrey De Smet commented on DROOLS-656: ----------------------------------------- Might not be possible on GitHub yet: http://stackoverflow.com/questions/13016119/how-to-set-the-receive-denynonfastforwards-on-a-repository-in-github > The blessed repo's should not accept a git force push > ----------------------------------------------------- > > Key: DROOLS-656 > URL: https://issues.jboss.org/browse/DROOLS-656 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > If someone ever git forces pushes to a blessed repo all hell will break loose. > We can prevent git forces pushes, as explained here: > http://stackoverflow.com/questions/1754491/is-there-a-way-to-configure-git-repository-to-reject-git-push-force > Force pushing on blessed repo's is very bad, but force pushing on forks is very common. > Requirements: > - Enable this on 1 new dummy blessed repository > - Prove you cannot force push to > - Prove you can fork it and force push to your fork. > - Delete the dummy blessed repository > - If that works well, enable it on the real blessed repositories -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 11:21:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 11:21:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4129) The RemotingLoginModule should first check if there is already a RealmUser In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023661#comment-13023661 ] RH Bugzilla Integration commented on WFLY-4129: ----------------------------------------------- Kabir Khan changed the Status of [bug 1168585|https://bugzilla.redhat.com/show_bug.cgi?id=1168585] from POST to MODIFIED > The RemotingLoginModule should first check if there is already a RealmUser > -------------------------------------------------------------------------- > > Key: WFLY-4129 > URL: https://issues.jboss.org/browse/WFLY-4129 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.0.Alpha1 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > > The reason is because the realm may have actually already substituted in a different name for the user. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 11:28:39 2014 From: issues at jboss.org (=?UTF-8?Q?Enrique_Gonz=C3=A1lez_Mart=C3=ADnez_=28JIRA=29?=) Date: Thu, 27 Nov 2014 11:28:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4133) Hanging EJB threads because of a persistent timer and failed deployment In-Reply-To: References: Message-ID: Enrique Gonz?lez Mart?nez created WFLY-4133: ----------------------------------------------- Summary: Hanging EJB threads because of a persistent timer and failed deployment Key: WFLY-4133 URL: https://issues.jboss.org/browse/WFLY-4133 Project: WildFly Issue Type: Bug Affects Versions: 9.0.0.Alpha1 Reporter: Enrique Gonz?lez Mart?nez Assignee: Enrique Gonz?lez Mart?nez When there is a time service with pending timeouts a bad redeploy can hang worker threads in the server. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 11:29:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 11:29:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4133) Hanging EJB threads because of a persistent timer and failed deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated WFLY-4133: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1147948 > Hanging EJB threads because of a persistent timer and failed deployment > ------------------------------------------------------------------------ > > Key: WFLY-4133 > URL: https://issues.jboss.org/browse/WFLY-4133 > Project: WildFly > Issue Type: Bug > Affects Versions: 9.0.0.Alpha1 > Reporter: Enrique Gonz?lez Mart?nez > Assignee: Enrique Gonz?lez Mart?nez > > When there is a time service with pending timeouts a bad redeploy can hang worker threads in the server. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 11:59:39 2014 From: issues at jboss.org (Eduardo Martins (JIRA)) Date: Thu, 27 Nov 2014 11:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4134) Java EE 7 Quickstarts In-Reply-To: References: Message-ID: Eduardo Martins created WFLY-4134: ------------------------------------- Summary: Java EE 7 Quickstarts Key: WFLY-4134 URL: https://issues.jboss.org/browse/WFLY-4134 Project: WildFly Issue Type: Task Reporter: Eduardo Martins Assignee: Eduardo Martins WildFly Quickstarts should demo the technologies introduced/updated by Java EE 7. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 12:11:39 2014 From: issues at jboss.org (Eduardo Martins (JIRA)) Date: Thu, 27 Nov 2014 12:11:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4135) EE Concurrency 1.0 Quickstarts In-Reply-To: References: Message-ID: Eduardo Martins created WFLY-4135: ------------------------------------- Summary: EE Concurrency 1.0 Quickstarts Key: WFLY-4135 URL: https://issues.jboss.org/browse/WFLY-4135 Project: WildFly Issue Type: Sub-task Reporter: Eduardo Martins Assignee: Eduardo Martins Update WildFly Quickstarts to demo usage of EE Concurrency 1.0, new technology introduced by Java EE 7. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 12:37:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 12:37:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-650) Sequential Phreak is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated DROOLS-650: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1168746 > Sequential Phreak is broken > ---------------------------- > > Key: DROOLS-650 > URL: https://issues.jboss.org/browse/DROOLS-650 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.0.1.Final, 6.1.0.Final, 6.2.0.CR2 > Reporter: Mark Proctor > Assignee: Mario Fusco > Fix For: 6.2.0.CR3 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 12:39:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 12:39:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-650) Sequential Phreak is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated DROOLS-650: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1168746, https://bugzilla.redhat.com/show_bug.cgi?id=1168747 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1168746) > Sequential Phreak is broken > ---------------------------- > > Key: DROOLS-650 > URL: https://issues.jboss.org/browse/DROOLS-650 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.0.1.Final, 6.1.0.Final, 6.2.0.CR2 > Reporter: Mark Proctor > Assignee: Mario Fusco > Fix For: 6.2.0.CR3 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 12:46:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 12:46:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-650) Sequential Phreak is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023683#comment-13023683 ] RH Bugzilla Integration commented on DROOLS-650: ------------------------------------------------ Mario Fusco changed the Status of [bug 1168746|https://bugzilla.redhat.com/show_bug.cgi?id=1168746] from NEW to ASSIGNED > Sequential Phreak is broken > ---------------------------- > > Key: DROOLS-650 > URL: https://issues.jboss.org/browse/DROOLS-650 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.0.1.Final, 6.1.0.Final, 6.2.0.CR2 > Reporter: Mark Proctor > Assignee: Mario Fusco > Fix For: 6.2.0.CR3 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Thu Nov 27 12:53:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 27 Nov 2014 12:53:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-650) Sequential Phreak is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023684#comment-13023684 ] RH Bugzilla Integration commented on DROOLS-650: ------------------------------------------------ Mario Fusco changed the Status of [bug 1168746|https://bugzilla.redhat.com/show_bug.cgi?id=1168746] from ASSIGNED to MODIFIED > Sequential Phreak is broken > ---------------------------- > > Key: DROOLS-650 > URL: https://issues.jboss.org/browse/DROOLS-650 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.0.1.Final, 6.1.0.Final, 6.2.0.CR2 > Reporter: Mark Proctor > Assignee: Mario Fusco > Fix For: 6.2.0.CR3 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 02:01:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 28 Nov 2014 02:01:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4109) Remove outdated policy files from testsuite/integration/src/test/config In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023751#comment-13023751 ] RH Bugzilla Integration commented on WFLY-4109: ----------------------------------------------- Petr Kremensky changed the Status of [bug 1166130|https://bugzilla.redhat.com/show_bug.cgi?id=1166130] from ON_QA to VERIFIED > Remove outdated policy files from testsuite/integration/src/test/config > ----------------------------------------------------------------------- > > Key: WFLY-4109 > URL: https://issues.jboss.org/browse/WFLY-4109 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > Priority: Minor > Fix For: 9.0.0.Beta1 > > > Policy files no-op.policy and permit_all_testsuite.policy are outdated. They should be removed. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 02:09:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 28 Nov 2014 02:09:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-286) The SecurityRealmService should only perform a generic mapping to RealmUser if really required. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023752#comment-13023752 ] RH Bugzilla Integration commented on WFCORE-286: ------------------------------------------------ Kabir Khan changed the Status of [bug 1168595|https://bugzilla.redhat.com/show_bug.cgi?id=1168595] from POST to MODIFIED > The SecurityRealmService should only perform a generic mapping to RealmUser if really required. > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-286 > URL: https://issues.jboss.org/browse/WFCORE-286 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > > If there is a more accurate way to calculate the RealmUser then use it. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 02:38:39 2014 From: issues at jboss.org (Michael Biarnes Kiefer (JIRA)) Date: Fri, 28 Nov 2014 02:38:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-199) The entire kie 6.3 build should move maven from 3.0.5 to 3.2.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023753#comment-13023753 ] Michael Biarnes Kiefer commented on DROOLS-199: ----------------------------------------------- tried to update tycho version to 0.21.0 and build droolsjbpm-toold with maven 3.2.3 but it is still not compiling: https://gist.github.com/mbiarnes/f7341948b7a2602ecc71 > The entire kie 6.3 build should move maven from 3.0.5 to 3.2.x > -------------------------------------------------------------- > > Key: DROOLS-199 > URL: https://issues.jboss.org/browse/DROOLS-199 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > Old description: > To reproduce: > - Install maven 3.1.0 > - Run mvn-all.sh clean install -Dfull > Note: Any changes to the pom must still allow them to run with 3.0.5 too. > 1) At least droolsjbpm-tools (drools-eclipse) is guaranteed to fail because it uses an older tycho version and only tycho 0.18.1 is compatible with maven 3.1.0 according to the tycho mailing list. > So the maven tycho plugin will need to be upgraded to 0.18.1 (which works with maven 3.0.5 too - so they say). > 2) There might be other surprises... -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 03:34:39 2014 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 28 Nov 2014 03:34:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4137) Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...) In-Reply-To: References: Message-ID: Tomas Hofman created WFLY-4137: ---------------------------------- Summary: Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...) Key: WFLY-4137 URL: https://issues.jboss.org/browse/WFLY-4137 Project: WildFly Issue Type: Bug Components: Web Services Affects Versions: 9.0.0.Alpha1 Reporter: Tomas Hofman Assignee: Tomas Hofman Clone of EAP6 issue https://bugzilla.redhat.com/show_bug.cgi?id=1167348 - WF is also susceptible. Description of problem: There is wrong content type (text/xml) in multipart SOAPMessage when sending it using javax.xml.soap API. So target system is unable to parse it. How reproducible: always Additional info: It's also wrong in EAP 6.2. EAP 6.1 is OK. There is a patch attached in BZ-1167348 for JBoss CXF 4.3.3. The same fix should be also applied to JBoss CXF 5.0.0 which is used by Wildfly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 03:49:39 2014 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 28 Nov 2014 03:49:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4137) Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hofman updated WFLY-4137: ------------------------------- Description: Clone of EAP6 issue https://bugzilla.redhat.com/show_bug.cgi?id=1167348 - WF is also susceptible. Description of problem: There is wrong content type (text/xml) in multipart SOAPMessage when sending it using javax.xml.soap API. So target system is unable to parse it. How reproducible: always Additional info: It's also wrong in EAP 6.2. EAP 6.1 is OK. There is a patch attached in BZ-1167348 for JBossWS CXF 4.3.3. The same fix should be also applied to JBossWS CXF 5.0.0 which is used by Wildfly. was: Clone of EAP6 issue https://bugzilla.redhat.com/show_bug.cgi?id=1167348 - WF is also susceptible. Description of problem: There is wrong content type (text/xml) in multipart SOAPMessage when sending it using javax.xml.soap API. So target system is unable to parse it. How reproducible: always Additional info: It's also wrong in EAP 6.2. EAP 6.1 is OK. There is a patch attached in BZ-1167348 for JBoss CXF 4.3.3. The same fix should be also applied to JBoss CXF 5.0.0 which is used by Wildfly. > Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...) > ------------------------------------------------------------------------------------------------- > > Key: WFLY-4137 > URL: https://issues.jboss.org/browse/WFLY-4137 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > Clone of EAP6 issue https://bugzilla.redhat.com/show_bug.cgi?id=1167348 - WF is also susceptible. > Description of problem: > There is wrong content type (text/xml) in multipart SOAPMessage when sending it using javax.xml.soap API. So target system is unable to parse it. > How reproducible: > always > Additional info: > It's also wrong in EAP 6.2. > EAP 6.1 is OK. > There is a patch attached in BZ-1167348 for JBossWS CXF 4.3.3. The same fix should be also applied to JBossWS CXF 5.0.0 which is used by Wildfly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 03:57:39 2014 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 28 Nov 2014 03:57:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4138) Upgrade JBossWS CXF from 5.0.0.Beta2 to 5.0.0.BetaX In-Reply-To: References: Message-ID: Tomas Hofman created WFLY-4138: ---------------------------------- Summary: Upgrade JBossWS CXF from 5.0.0.Beta2 to 5.0.0.BetaX Key: WFLY-4138 URL: https://issues.jboss.org/browse/WFLY-4138 Project: WildFly Issue Type: Component Upgrade Components: Web Services Affects Versions: 9.0.0.Alpha1 Reporter: Tomas Hofman Assignee: Alessio Soldano JBossWS CXF needs upgrade because of WFLY-4137. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 04:00:40 2014 From: issues at jboss.org (Tomas Hofman (JIRA)) Date: Fri, 28 Nov 2014 04:00:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4137) Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hofman updated WFLY-4137: ------------------------------- Tester: Martin Swiech > Wrong content type (text/xml) in outgoing multipart SOAPMessage (expected multipart/related; ...) > ------------------------------------------------------------------------------------------------- > > Key: WFLY-4137 > URL: https://issues.jboss.org/browse/WFLY-4137 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > Clone of EAP6 issue https://bugzilla.redhat.com/show_bug.cgi?id=1167348 - WF is also susceptible. > Description of problem: > There is wrong content type (text/xml) in multipart SOAPMessage when sending it using javax.xml.soap API. So target system is unable to parse it. > How reproducible: > always > Additional info: > It's also wrong in EAP 6.2. > EAP 6.1 is OK. > There is a patch attached in BZ-1167348 for JBossWS CXF 4.3.3. The same fix should be also applied to JBossWS CXF 5.0.0 which is used by Wildfly. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 04:57:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 28 Nov 2014 04:57:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-57) Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023786#comment-13023786 ] RH Bugzilla Integration commented on WFCORE-57: ----------------------------------------------- Kabir Khan changed the Status of [bug 1070214|https://bugzilla.redhat.com/show_bug.cgi?id=1070214] from POST to MODIFIED > Deprecated resource is present in r-r-d of /subsystem=security/security-domain=* > -------------------------------------------------------------------------------- > > Key: WFCORE-57 > URL: https://issues.jboss.org/browse/WFCORE-57 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha4 > Reporter: Harald Pehl > Assignee: Emmanuel Hugonnet > Priority: Minor > Fix For: 1.0.0.Alpha9 > > > When executing > {code} > /subsystem=security/security-domain=*:read-resource-description(recursive-depth=2) > {code} > the acl subresource contains both the deprecated child-resource {{login-module}} and the new one called {{acl-module}}: > {code} > ... > "acl" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > "model-description" => {"classic" => { > "description" => "Access control list configuration. Configures a list of ACL modules to be used.", > ... > "operations" => undefined, > "children" => { > "acl-module" => { > "description" => "ACL module", > "model-description" => {"*" => { > "description" => "List of authentication modules", > ... > "operations" => undefined, > "children" => {} > }} > }, > "login-module" => { > "description" => "Login module", > "model-description" => {"*" => undefined} > } > } > }} > }, > ... > {code} > However the deprecated subresource {{login-modules}} should only appear if setting {{include-aliases=true}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 04:57:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 28 Nov 2014 04:57:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4013) The value of the bound attribute in socket-binding-group messaging is always false In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023787#comment-13023787 ] RH Bugzilla Integration commented on WFLY-4013: ----------------------------------------------- Kabir Khan changed the Status of [bug 1156360|https://bugzilla.redhat.com/show_bug.cgi?id=1156360] from NEW to MODIFIED > The value of the bound attribute in socket-binding-group messaging is always false > ---------------------------------------------------------------------------------- > > Key: WFLY-4013 > URL: https://issues.jboss.org/browse/WFLY-4013 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: JBoss AS7 7.2.0.Final > Environment: JBoss EAP 6.3.1. > Reporter: Tom Ross > Assignee: Jeff Mesnil > Fix For: 9.0.0.Beta1 > > > The value of bound attribute in messaging socket group is always false. > {noformat} > /socket-binding-group=standard-sockets/socket-binding=messaging:read-resource(include-runtime=true, recursive=true) > { > "outcome" => "success", > "result" => { > "bound" => false, > "bound-address" => undefined, > "bound-port" => undefined, > "client-mappings" => undefined, > "fixed-port" => false, > "interface" => undefined, > "multicast-address" => undefined, > "multicast-port" => undefined, > "name" => "messaging", > "port" => 5445 > } > {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 04:58:40 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 28 Nov 2014 04:58:40 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-260) Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023789#comment-13023789 ] RH Bugzilla Integration commented on WFCORE-260: ------------------------------------------------ Kabir Khan changed the Status of [bug 1161589|https://bugzilla.redhat.com/show_bug.cgi?id=1161589] from POST to MODIFIED > Incorrect LoginModule name used for Kerberos with IBM JDK and incorrect case for useKeytab > ------------------------------------------------------------------------------------------ > > Key: WFCORE-260 > URL: https://issues.jboss.org/browse/WFCORE-260 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha14 > > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 05:11:39 2014 From: issues at jboss.org (Brent Douglas (JIRA)) Date: Fri, 28 Nov 2014 05:11:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4139) JBatch module dependencies not configured for valid deployments In-Reply-To: References: Message-ID: Brent Douglas created WFLY-4139: ----------------------------------- Summary: JBatch module dependencies not configured for valid deployments Key: WFLY-4139 URL: https://issues.jboss.org/browse/WFLY-4139 Project: WildFly Issue Type: Bug Components: Batch Affects Versions: 9.0.0.Alpha1, 8.2.0.Final Environment: Fedora 19, JDK 8u25, wildfly-dist:9.0.0.Alpha1 Reporter: Brent Douglas Assignee: Jason Greene In BatchEnvironmentProcessor the JBatch subsystem only adds a dependency on wildfly's transaction manager and bean manager if some marker files are detected. (See here) https://github.com/wildfly/wildfly/blob/bfc41360196f5183a005101bf7ac2d7bfa1389c0/batch/extension/src/main/java/org/wildfly/extension/batch/deployment/BatchEnvironmentProcessor.java#L73 If they are not detected an unhelpful exception is thrown when instantiating the JobOperator: {noformat} 01:18:25,442 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0009: Undeployed "test.war" (runtime-name: "test.war") Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 248.119 sec <<< FAILURE! - in io.machinecode.chainlink.ee.wildfly.WildFlyTest testGlassfish(io.machinecode.chainlink.ee.wildfly.WildFlyTest) Time elapsed: 0.336 sec <<< ERROR! java.util.ServiceConfigurationError: javax.batch.operations.JobOperator: Provider org.jberet.operations.JobOperatorImpl could not be instantiated at org.wildfly.jberet.services.BatchEnvironmentService$WildFlyBatchEnvironment.getArtifactFactory(BatchEnvironmentService.java:123) at org.wildfly.jberet.DelegatingBatchEnvironment.getArtifactFactory(DelegatingBatchEnvironment.java:52) at org.jberet.operations.JobOperatorImpl.(JobOperatorImpl.java:89) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at java.lang.Class.newInstance(Class.java:438) at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380) at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) at java.util.ServiceLoader$1.next(ServiceLoader.java:480) at javax.batch.runtime.BatchRuntime.getJobOperator(BatchRuntime.java:57) at io.machinecode.chainlink.ee.wildfly.WildFlyTest.testGlassfish(WildFlyTest.java:36) {noformat} There are valid reasons that these marker files may not be in the deployment, an example being that the deployment might only read metadata from jobs started by other deployments from the configured repository. This check also does not take into account jars in a war's lib dir (for example if you try and run a test using arquillian) or in an ear, which should be allowed. I think there should be two changes. Firstly, those dependencies should be added unconditionally as there are cases where these marker will not be present and they will still be required. Secondly, the exception thrown because the beanManager has not been configured should be thrown earlier in the lifecycle where it will generate a real error message (perhaps in BatchEnvironmentService#start before creating the WildFlyBatchEnvironment where it can first be detected): https://github.com/wildfly/wildfly/blob/bfc41360196f5183a005101bf7ac2d7bfa1389c0/batch/jberet/src/main/java/org/wildfly/jberet/services/BatchEnvironmentService.java#L71 -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 08:36:39 2014 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Fri, 28 Nov 2014 08:36:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4140) In some case :activare on resource-adapter fails if id != archive_name In-Reply-To: References: Message-ID: Stefano Maestri created WFLY-4140: ------------------------------------- Summary: In some case :activare on resource-adapter fails if id != archive_name Key: WFLY-4140 URL: https://issues.jboss.org/browse/WFLY-4140 Project: WildFly Issue Type: Feature Request Components: JCA Reporter: Stefano Maestri Assignee: Stefano Maestri deploy /home/jolee/amq.rar /subsystem=resource-adapters/resource-adapter=amq:add(archive=amq.rar,transaction-support=XATransaction) /subsystem=resource-adapters/resource-adapter=amq/config-properties=UseInboundSession:add(value=false) /subsystem=resource-adapters/resource-adapter=amq/config-properties=ServerUrl:add(value="vm://localhost") /subsystem=resource-adapters/resource-adapter=amq/config-properties=BrokerXmlConfig:add(value="xbean:broker-config.xml") /subsystem=resource-adapters/resource-adapter=amq/connection-definitions=ConnectionFactory:add(jndi-name=java:jboss/ConnectionFactory,use-java-context=true,class-name=org.apache.activemq.ra.ActiveMQManagedConnectionFactory,enabled=true) /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAIProcessStarter:add(jndi-name=java:jboss/queue/EAIProcessStarter,use-java-context=false,class-name=org.apache.activemq.command.ActiveMQQueue,enabled=true) /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAIProcessStarter/config-properties=PhysicalName:add(value=EAIProcessStarter) /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAI_TRIGGER:add(jndi-name=java:/jboss/queue/EAI_TRIGGER,use-java-context=true,class-name=org.apache.activemq.command.ActiveMQQueue,enabled=true) /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAI_TRIGGER/config-properties=PhysicalName:add(value=EAI_TRIGGER) /subsystem=resource-adapters/resource-adapter=amq:activate [4] [standalone at localhost:9999 /] run-batch --file=/home/jolee/rar2.cli {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-10" => "JBAS010480: RAR 'amq' not yet deployed."}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 08:39:39 2014 From: issues at jboss.org (Stefano Maestri (JIRA)) Date: Fri, 28 Nov 2014 08:39:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4140) In some case :activare on resource-adapter fails if id != archive_name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefano Maestri updated WFLY-4140: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/7007 (was: https://c.na7.visual.force.com/apex/Case_View?sbstr=00910815) > In some case :activare on resource-adapter fails if id != archive_name > ---------------------------------------------------------------------- > > Key: WFLY-4140 > URL: https://issues.jboss.org/browse/WFLY-4140 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > deploy /home/jolee/amq.rar > /subsystem=resource-adapters/resource-adapter=amq:add(archive=amq.rar,transaction-support=XATransaction) > /subsystem=resource-adapters/resource-adapter=amq/config-properties=UseInboundSession:add(value=false) > /subsystem=resource-adapters/resource-adapter=amq/config-properties=ServerUrl:add(value="vm://localhost") > /subsystem=resource-adapters/resource-adapter=amq/config-properties=BrokerXmlConfig:add(value="xbean:broker-config.xml") > /subsystem=resource-adapters/resource-adapter=amq/connection-definitions=ConnectionFactory:add(jndi-name=java:jboss/ConnectionFactory,use-java-context=true,class-name=org.apache.activemq.ra.ActiveMQManagedConnectionFactory,enabled=true) > /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAIProcessStarter:add(jndi-name=java:jboss/queue/EAIProcessStarter,use-java-context=false,class-name=org.apache.activemq.command.ActiveMQQueue,enabled=true) > /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAIProcessStarter/config-properties=PhysicalName:add(value=EAIProcessStarter) > /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAI_TRIGGER:add(jndi-name=java:/jboss/queue/EAI_TRIGGER,use-java-context=true,class-name=org.apache.activemq.command.ActiveMQQueue,enabled=true) > /subsystem=resource-adapters/resource-adapter=amq/admin-objects=EAI_TRIGGER/config-properties=PhysicalName:add(value=EAI_TRIGGER) > /subsystem=resource-adapters/resource-adapter=amq:activate > [4] > [standalone at localhost:9999 /] run-batch --file=/home/jolee/rar2.cli > {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-10" => "JBAS010480: RAR 'amq' not yet deployed."}} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 09:00:42 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 28 Nov 2014 09:00:42 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-274) The CLI command "read-boot-errors" does not include the timestamp of the error event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023848#comment-13023848 ] RH Bugzilla Integration commented on WFCORE-274: ------------------------------------------------ Emmanuel Hugonnet (ehsavoie) changed the Status of [bug 1160898|https://bugzilla.redhat.com/show_bug.cgi?id=1160898] from ASSIGNED to POST > The CLI command "read-boot-errors" does not include the timestamp of the error event > ------------------------------------------------------------------------------------ > > Key: WFCORE-274 > URL: https://issues.jboss.org/browse/WFCORE-274 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > The CLI command "read-boot-errors" does not include the timestamp of the error event. For anyone using this command for diagnostic purposes, the absence of an event's timestamp decreases the usefulness of the information. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 13:50:39 2014 From: issues at jboss.org (Jose Cavieres (JIRA)) Date: Fri, 28 Nov 2014 13:50:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-658) External POJOs not shown in Workbench after reopen the project In-Reply-To: References: Message-ID: Jose Cavieres created DROOLS-658: ------------------------------------ Summary: External POJOs not shown in Workbench after reopen the project Key: DROOLS-658 URL: https://issues.jboss.org/browse/DROOLS-658 Project: Drools Issue Type: Bug Affects Versions: 6.2.0.CR2, 6.1.0.Final Environment: linux 64 bits Reporter: Jose Cavieres Assignee: Mark Proctor In order to reuse some POJOs, I followed the procedure defined in http://mswiderski.blogspot.com/2014/02/reuse-your-business-assets-with-jbpm-6.html and added a POJO to the "reusable project" (named Papito) Everything works fine the first time one uses those clases in the "top project" (named Hijita) . POJOs of the "reusable project" are prefixed with the string "-ext-" in the Java editor of the "top project" just as explained in "15.7.6.6.3. Using the external objects" of the document: http://docs.jboss.org/drools/release/6.1.0.Final/drools- docs/html/wb.Workbench.html#wb.DataModeller The problem is that only happens the first time. If one logout and the login again, the "-ext" classes are no longer shown as valid Types por the POJOs in the "top project" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 13:53:39 2014 From: issues at jboss.org (Jose Cavieres (JIRA)) Date: Fri, 28 Nov 2014 13:53:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-658) External POJOs not shown in Workbench after reopen the project In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jose Cavieres updated DROOLS-658: --------------------------------- Description: In order to reuse some POJOs, I followed the procedure defined in http://mswiderski.blogspot.com/2014/02/reuse-your-business-assets-with-jbpm-6.html and added a POJO to the "reusable project" (named Papito) Everything works fine the first time one uses those clases in the "top project" (named Hijita) . POJOs of the "reusable project" are prefixed with the string "- ext -" in the Java editor of the "top project" just as explained in "15.7.6.6.3. Using the external objects" of the document: http://docs.jboss.org/drools/release/6.1.0.Final/drools- docs/html/wb.Workbench.html#wb.DataModeller The problem is that only happens the first time. If one logout and the login again, the "-ext" classes are no longer shown as valid Types por the POJOs in the "top project" was: In order to reuse some POJOs, I followed the procedure defined in http://mswiderski.blogspot.com/2014/02/reuse-your-business-assets-with-jbpm-6.html and added a POJO to the "reusable project" (named Papito) Everything works fine the first time one uses those clases in the "top project" (named Hijita) . POJOs of the "reusable project" are prefixed with the string "-ext-" in the Java editor of the "top project" just as explained in "15.7.6.6.3. Using the external objects" of the document: http://docs.jboss.org/drools/release/6.1.0.Final/drools- docs/html/wb.Workbench.html#wb.DataModeller The problem is that only happens the first time. If one logout and the login again, the "-ext" classes are no longer shown as valid Types por the POJOs in the "top project" Steps to Reproduce: 1. Follow http://mswiderski.blogspot.com/2014/02/reuse-your-business-assets-with-jbpm-6.html creating one POJO in "reusable project" 2. LogOut / Log/in 3. Goto the Data Modeler/Java Editor of the "top project" 4. The POJO created in 1 doesn't show as a valid Type > External POJOs not shown in Workbench after reopen the project > -------------------------------------------------------------- > > Key: DROOLS-658 > URL: https://issues.jboss.org/browse/DROOLS-658 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: linux 64 bits > Reporter: Jose Cavieres > Assignee: Mark Proctor > > In order to reuse some POJOs, I followed the procedure defined in > http://mswiderski.blogspot.com/2014/02/reuse-your-business-assets-with-jbpm-6.html > and added a POJO to the "reusable project" (named Papito) > Everything works fine the first time one uses those clases in the "top project" (named Hijita) . POJOs of the "reusable project" are prefixed with the string "- ext -" in the Java editor of the "top project" just as explained in "15.7.6.6.3. Using the external objects" of the document: > http://docs.jboss.org/drools/release/6.1.0.Final/drools- > docs/html/wb.Workbench.html#wb.DataModeller > The problem is that only happens the first time. If one logout and the login again, the "-ext" classes are no longer shown as valid Types por the POJOs in the "top project" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 13:55:39 2014 From: issues at jboss.org (Jose Cavieres (JIRA)) Date: Fri, 28 Nov 2014 13:55:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-658) External POJOs not shown in Workbench after reopen the project In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jose Cavieres updated DROOLS-658: --------------------------------- Description: In order to reuse some POJOs, I followed the procedure defined in http://mswiderski.blogspot.com/2014/02/reuse-your-business-assets-with-jbpm-6.html and added a POJO to the "reusable project" (named Papito) Everything works fine the first time one uses those clases in the "top project" (named Hijita) . POJOs of the "reusable project" are prefixed with the string "- ext -" in the Java editor of the "top project" just as explained in "15.7.6.6.3. Using the external objects" of the document: http://docs.jboss.org/drools/release/6.1.0.Final/drools-docs/html/wb.Workbench.html#wb.DataModeller The problem is that only happens the first time. If one logout and the login again, the "-ext" classes are no longer shown as valid Types por the POJOs in the "top project" was: In order to reuse some POJOs, I followed the procedure defined in http://mswiderski.blogspot.com/2014/02/reuse-your-business-assets-with-jbpm-6.html and added a POJO to the "reusable project" (named Papito) Everything works fine the first time one uses those clases in the "top project" (named Hijita) . POJOs of the "reusable project" are prefixed with the string "- ext -" in the Java editor of the "top project" just as explained in "15.7.6.6.3. Using the external objects" of the document: http://docs.jboss.org/drools/release/6.1.0.Final/drools- docs/html/wb.Workbench.html#wb.DataModeller The problem is that only happens the first time. If one logout and the login again, the "-ext" classes are no longer shown as valid Types por the POJOs in the "top project" > External POJOs not shown in Workbench after reopen the project > -------------------------------------------------------------- > > Key: DROOLS-658 > URL: https://issues.jboss.org/browse/DROOLS-658 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: linux 64 bits > Reporter: Jose Cavieres > Assignee: Mark Proctor > > In order to reuse some POJOs, I followed the procedure defined in > http://mswiderski.blogspot.com/2014/02/reuse-your-business-assets-with-jbpm-6.html > and added a POJO to the "reusable project" (named Papito) > Everything works fine the first time one uses those clases in the "top project" (named Hijita) . POJOs of the "reusable project" are prefixed with the string "- ext -" in the Java editor of the "top project" just as explained in "15.7.6.6.3. Using the external objects" of the document: > http://docs.jboss.org/drools/release/6.1.0.Final/drools-docs/html/wb.Workbench.html#wb.DataModeller > The problem is that only happens the first time. If one logout and the login again, the "-ext" classes are no longer shown as valid Types por the POJOs in the "top project" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 13:59:39 2014 From: issues at jboss.org (Jose Cavieres (JIRA)) Date: Fri, 28 Nov 2014 13:59:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (DROOLS-658) External POJOs not shown in Workbench after reopen the project In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/DROOLS-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jose Cavieres updated DROOLS-658: --------------------------------- Attachment: reuse.tgz Added both projects Papito="reusable project" and Hijita="top project", according to the names used in http://mswiderski.blogspot.com/2014/02/reuse-your-business-assets-with-jbpm-6.html > External POJOs not shown in Workbench after reopen the project > -------------------------------------------------------------- > > Key: DROOLS-658 > URL: https://issues.jboss.org/browse/DROOLS-658 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR2 > Environment: linux 64 bits > Reporter: Jose Cavieres > Assignee: Mark Proctor > Attachments: reuse.tgz > > > In order to reuse some POJOs, I followed the procedure defined in > http://mswiderski.blogspot.com/2014/02/reuse-your-business-assets-with-jbpm-6.html > and added a POJO to the "reusable project" (named Papito) > Everything works fine the first time one uses those clases in the "top project" (named Hijita) . POJOs of the "reusable project" are prefixed with the string "- ext -" in the Java editor of the "top project" just as explained in "15.7.6.6.3. Using the external objects" of the document: > http://docs.jboss.org/drools/release/6.1.0.Final/drools-docs/html/wb.Workbench.html#wb.DataModeller > The problem is that only happens the first time. If one logout and the login again, the "-ext" classes are no longer shown as valid Types por the POJOs in the "top project" -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 18:22:39 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 28 Nov 2014 18:22:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4136) sql parameter log issue spy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated WFLY-4136: -------------------------------- Security: (was: Security Issue) > sql parameter log issue spy > --------------------------- > > Key: WFLY-4136 > URL: https://issues.jboss.org/browse/WFLY-4136 > Project: WildFly > Issue Type: Feature Request > Components: Logging > Affects Versions: 8.2.0.Final > Environment: NA > Reporter: Gulam Samdani > Assignee: James Perkins > Priority: Critical > Labels: jboss > Fix For: 9.0.0.Beta1 > > > problem description is here . > https://developer.jboss.org/thread/250027 > most of time several people not interested on jboss because this missing feature . it is important for development . but it is not impossible . so , > please add this feature next version . already all server tomcat , glassfish support this , why can not jboss offer this feature . > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 18:25:39 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Fri, 28 Nov 2014 18:25:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4136) sql parameter log issue spy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins updated WFLY-4136: -------------------------------- Security Sensitive Issue: (was: Check in case of security relevant issue) Fix Version/s: (was: 9.0.0.Beta1) Priority: Minor (was: Critical) Labels: (was: jboss) Assignee: Jesper Pedersen (was: James Perkins) Component/s: JCA (was: Logging) This is not a logging issue. This should likely just be closed, but I'm not sure familiar with how the "spy" attribute works. Assigning to JCA to see if they have anything to add. > sql parameter log issue spy > --------------------------- > > Key: WFLY-4136 > URL: https://issues.jboss.org/browse/WFLY-4136 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Affects Versions: 8.2.0.Final > Environment: NA > Reporter: Gulam Samdani > Assignee: Jesper Pedersen > Priority: Minor > > problem description is here . > https://developer.jboss.org/thread/250027 > most of time several people not interested on jboss because this missing feature . it is important for development . but it is not impossible . so , > please add this feature next version . already all server tomcat , glassfish support this , why can not jboss offer this feature . > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Fri Nov 28 23:32:39 2014 From: issues at jboss.org (Gulam Samdani (JIRA)) Date: Fri, 28 Nov 2014 23:32:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4136) sql parameter log issue spy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gulam Samdani updated WFLY-4136: -------------------------------- Priority: Critical (was: Minor) > sql parameter log issue spy > --------------------------- > > Key: WFLY-4136 > URL: https://issues.jboss.org/browse/WFLY-4136 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Affects Versions: 8.2.0.Final > Environment: NA > Reporter: Gulam Samdani > Assignee: Jesper Pedersen > Priority: Critical > > problem description is here . > https://developer.jboss.org/thread/250027 > most of time several people not interested on jboss because this missing feature . it is important for development . but it is not impossible . so , > please add this feature next version . already all server tomcat , glassfish support this , why can not jboss offer this feature . > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 29 02:15:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sat, 29 Nov 2014 02:15:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-216) Add ModelValidator to ensure resource model is correct In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023920#comment-13023920 ] RH Bugzilla Integration commented on WFCORE-216: ------------------------------------------------ Kabir Khan changed the Status of [bug 1023064|https://bugzilla.redhat.com/show_bug.cgi?id=1023064] from POST to MODIFIED > Add ModelValidator to ensure resource model is correct > ------------------------------------------------------ > > Key: WFCORE-216 > URL: https://issues.jboss.org/browse/WFCORE-216 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Stefano Maestri > Assignee: Tomaz Cerar > Fix For: 1.0.0.Alpha12 > > > Currently there is no validation of "requires" and "alternatives" that are specified in attribute metadata / AttributeDefinition > ModelValidator should be added as extra step handler that executes on end of MODEL phase to ensure resource model is correct. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 29 02:15:41 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sat, 29 Nov 2014 02:15:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-2376) DataSource properties are not persisting via CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023921#comment-13023921 ] RH Bugzilla Integration commented on WFLY-2376: ----------------------------------------------- Kabir Khan changed the Status of [bug 1023064|https://bugzilla.redhat.com/show_bug.cgi?id=1023064] from POST to MODIFIED > DataSource properties are not persisting via CLI > ------------------------------------------------ > > Key: WFLY-2376 > URL: https://issues.jboss.org/browse/WFLY-2376 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 8.0.0.Beta1 > Reporter: Jay Kumar SenSharma > Assignee: Stefano Maestri > Fix For: 9.0.0.Beta1 > > > - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration: > {quote} > ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)" > "stale-connection-checker-properties" => { > "type" => OBJECT, > "description" => "The stale connection checker properties", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "reauth-plugin-properties" => { > "type" => OBJECT, > "description" => "The properties for the reauthentication plugin", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > "exception-sorter-properties" => { > "type" => OBJECT, > "description" => "The exception sorter properties", > "expressions-allowed" => true, > "nillable" => true, > "value-type" => STRING, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {quote} > - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource. > ./jboss-cli.sh --user=admin --password=admin at 123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})" > - The Generated DataSource looks like following: > ${quote} > > jdbc:oracle:thin:@DBHostName:1521:DBName > ojdbc6.jar > select 1 from dual > > user > pass > > > > select 2 from dual > > > ${quote} -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 29 02:23:39 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sat, 29 Nov 2014 02:23:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFCORE-274) The CLI command "read-boot-errors" does not include the timestamp of the error event In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFCORE-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023922#comment-13023922 ] RH Bugzilla Integration commented on WFCORE-274: ------------------------------------------------ Kabir Khan changed the Status of [bug 1160898|https://bugzilla.redhat.com/show_bug.cgi?id=1160898] from POST to MODIFIED > The CLI command "read-boot-errors" does not include the timestamp of the error event > ------------------------------------------------------------------------------------ > > Key: WFCORE-274 > URL: https://issues.jboss.org/browse/WFCORE-274 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha13 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > The CLI command "read-boot-errors" does not include the timestamp of the error event. For anyone using this command for diagnostic purposes, the absence of an event's timestamp decreases the usefulness of the information. -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 29 15:14:39 2014 From: issues at jboss.org (James Perkins (JIRA)) Date: Sat, 29 Nov 2014 15:14:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-4136) sql parameter log issue spy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Perkins closed WFLY-4136. ------------------------------- Resolution: Rejected After looking into there is no issue here. The way the spy logs the information is correct. > sql parameter log issue spy > --------------------------- > > Key: WFLY-4136 > URL: https://issues.jboss.org/browse/WFLY-4136 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Affects Versions: 8.2.0.Final > Environment: NA > Reporter: Gulam Samdani > Assignee: Jesper Pedersen > Priority: Critical > > problem description is here . > https://developer.jboss.org/thread/250027 > most of time several people not interested on jboss because this missing feature . it is important for development . but it is not impossible . so , > please add this feature next version . already all server tomcat , glassfish support this , why can not jboss offer this feature . > -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 29 16:13:39 2014 From: issues at jboss.org (Vsevolod Golovanov (JIRA)) Date: Sat, 29 Nov 2014 16:13:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3931) Custom formatter property changes not written to, but overriden by logging.properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vsevolod Golovanov updated WFLY-3931: ------------------------------------- Attachment: standalone.xml [~ander.parra], here, it's just a fresh standalone.xml with the following added: {code} {code} No more configuration or code needed to reproduce. > Custom formatter property changes not written to, but overriden by logging.properties > ------------------------------------------------------------------------------------- > > Key: WFLY-3931 > URL: https://issues.jboss.org/browse/WFLY-3931 > Project: WildFly > Issue Type: Bug > Components: Logging > Affects Versions: 8.1.0.Final > Environment: Wildfly 8.1.0.Final > Reporter: Vsevolod Golovanov > Assignee: James Perkins > Attachments: standalone.xml > > > When you first add custom formatter with properties to standalone.xml, on server start property values get correctly resolved and written to logging.properties. > If you change property values in standalone.xml of an existing custom formatter, that was flushed to logging.properties before, then on the next server start new values don't get written to logging.properties and formatter instance gets the old values from logging.properties. > For properties with static values that are defined in standalone.xml there is a workaround: change the custom formatter name each time you change a property value. > But with more dynamic properties, e.g. that rely on system properties, it's not so simple... -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 29 16:15:41 2014 From: issues at jboss.org (Vsevolod Golovanov (JIRA)) Date: Sat, 29 Nov 2014 16:15:41 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-3931) Custom formatter property changes not written to, but overriden by logging.properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13023933#comment-13023933 ] Vsevolod Golovanov edited comment on WFLY-3931 at 11/29/14 4:14 PM: -------------------------------------------------------------------- [~ander.parra], [^standalone.xml] - it's just a fresh standalone.xml with the following added: {code} {code} No more configuration or code needed to reproduce. was (Author: vsevolodgolovanov): [~ander.parra], here, it's just a fresh standalone.xml with the following added: {code} {code} No more configuration or code needed to reproduce. > Custom formatter property changes not written to, but overriden by logging.properties > ------------------------------------------------------------------------------------- > > Key: WFLY-3931 > URL: https://issues.jboss.org/browse/WFLY-3931 > Project: WildFly > Issue Type: Bug > Components: Logging > Affects Versions: 8.1.0.Final > Environment: Wildfly 8.1.0.Final > Reporter: Vsevolod Golovanov > Assignee: James Perkins > Attachments: standalone.xml > > > When you first add custom formatter with properties to standalone.xml, on server start property values get correctly resolved and written to logging.properties. > If you change property values in standalone.xml of an existing custom formatter, that was flushed to logging.properties before, then on the next server start new values don't get written to logging.properties and formatter instance gets the old values from logging.properties. > For properties with static values that are defined in standalone.xml there is a workaround: change the custom formatter name each time you change a property value. > But with more dynamic properties, e.g. that rely on system properties, it's not so simple... -- This message was sent by Atlassian JIRA (v6.3.8#6338) From issues at jboss.org Sat Nov 29 16:38:39 2014 From: issues at jboss.org (Tomasz Adamski (JIRA)) Date: Sat, 29 Nov 2014 16:38:39 -0500 (EST) Subject: [jboss-jira] [JBoss JIRA] (WFLY-670) Using "attribute" tag causes injection of null values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/WFLY-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomasz Adamski resolved WFLY-670. --------------------------------- Resolution: Rejected Injecting null values on undeploy is expected and it should be handled in the code. > Using "attribute" tag causes injection of null values > ----------------------------------------------------- > > Key: WFLY-670 > URL: https://issues.jboss.org/browse/WFLY-670 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Anders Welen > Assignee: Tomasz Adamski > Priority: Minor > Fix For: Awaiting Volunteers > > > Using "attribute" tag in "jboss-service.xml" in a SAR archive causes injection of null values. Even if your code can handle this it makes it impossible to use primitive datatypes. -- This message was sent by Atlassian JIRA (v6.3.8#6338)