[JBoss JIRA] (WFLY-4280) Component upgrade of Hibernate Validator to version 5.1.next.Final when HV-861 is fixed
by Juan Hernández (JIRA)
[ https://issues.jboss.org/browse/WFLY-4280?page=com.atlassian.jira.plugin.... ]
Juan Hernández commented on WFLY-4280:
--------------------------------------
I tested this in Fedora 21, where only OpenJDK 8 is available. But I just downloaded and tested with the latest JDK 7 from Oracle (for Linux):
{noformat}
# java -version
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)
{noformat}
The result is the same.
As the problem seems to be related to the presence of synthentic bridge methods it may be relevant the compiler that you are using. May it help if I send you the built binaries that I'm using?
> Component upgrade of Hibernate Validator to version 5.1.next.Final when HV-861 is fixed
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-4280
> URL: https://issues.jboss.org/browse/WFLY-4280
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Fedora 21, OpenJDK 1.8.0_25-b18.
> Reporter: Juan Hernández
> Assignee: Scott Marlow
> Attachments: hv-861.tar.gz
>
>
> The version of Hibernate Validator included in WildFly 8.1 and 8.2 throws an {{ArrayIndexOutOfBounds}} exception when deploying some applications. This is already reported in the Hibernate Validator JIRA:
> https://hibernate.atlassian.net/browse/HV-861
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-3839) EjbClient: No cluster node manager found for node XY during server restart
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3839?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3839:
-----------------------------------------------
Tomas Hofman <thofman(a)redhat.com> changed the Status of [bug 959638|https://bugzilla.redhat.com/show_bug.cgi?id=959638] from NEW to ASSIGNED
> EjbClient: No cluster node manager found for node XY during server restart
> ---------------------------------------------------------------------------
>
> Key: WFLY-3839
> URL: https://issues.jboss.org/browse/WFLY-3839
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 8.1.0.Final
> Reporter: Dominik Pospisil
> Assignee: Richard Achmatowicz
>
> Situation: 4-node cluster, one node is failed at a time, during the whole test, clients are accessing stateless clustered EJB3. The failure type in this particular case is simulating server crash: JVM is killed using kill -9.
> When the server was starting, being brought back, we saw this error:
> 16:05:29,966 ERROR [org.jboss.ejb.client.ClusterContext] (ejb-client-cluster-node-connection-creation-2-thread-17) Cannot create EJBReceiver since no cluster node manager found for node perf20 in cluster context for cluster ejb
> Here is the log output again with context, the server was starting:
> {noformat}
> 16:05:29,966 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> 16:05:29,966 ERROR [org.jboss.ejb.client.ClusterContext] (ejb-client-cluster-node-connection-creation-2-thread-17) Cannot create EJBReceiver since no cluster node manager found for node perf20 in cluster context for cluster ejb
> 16:05:29,974 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> 16:05:29,974 ERROR [org.jboss.ejb.client.ClusterContext] (ejb-client-cluster-node-connection-creation-2-thread-18) Cannot create EJBReceiver since no cluster node manager found for node perf20 in cluster context for cluster ejb
> 16:05:29,975 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at java.lang.Thread.run(Thread.java:662)
> 16:05:29,975 INFO [org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler] (Remoting "config-based-ejb-client-endpoint" task-2) Retrying invocation which failed on node perf20 with exception:
> javax.ejb.NoSuchEJBException: No such EJB[appname=clusterbench-ee6,modulename=clusterbench-ee6-ejb,distinctname=,beanname=RemoteStatelessSBImpl]
> at org.jboss.ejb.client.remoting.NoSuchEJBExceptionResponseHandler.processMessage(NoSuchEJBExceptionResponseHandler.java:64)
> at org.jboss.ejb.client.remoting.ChannelAssociation.processResponse(ChannelAssociation.java:366)
> at org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver.handleMessage(ChannelAssociation.java:458)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:373)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> {noformat}
> During the whole test, there were 4 server crashes and startups (1 for each node), but only 3 occurences of the above mentioned error. These cluster nodes are perf18, perf19, perf20, perf21, but this error was seen only for perf20 (two occurences) and perf18 (one occurence).
> I did not find anything suspicious in the server.log of perf20.
> Cache: REPL_ASYNC
> Versions: EAP 6.1.0.ER6, ejb-client 1.0.19.Final
> Link to hudson job:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-ejb-...
> Server log:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-ejb-...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (REMJMX-84) Jboss JMX: Operation failed with status WAITING
by Piotr Findeisen (JIRA)
[ https://issues.jboss.org/browse/REMJMX-84?page=com.atlassian.jira.plugin.... ]
Piotr Findeisen commented on REMJMX-84:
---------------------------------------
I'm not, i use JBoss for development of my application. It appears client with 1.1.3.Final can connect to JBoss 7. This does not yet mean _everything_ is going to work, but let's hope so :)
> Jboss JMX: Operation failed with status WAITING
> ------------------------------------------------
>
> Key: REMJMX-84
> URL: https://issues.jboss.org/browse/REMJMX-84
> Project: Remoting JMX
> Issue Type: Bug
> Environment: jboss-as-7.1.1.Final on windows server
> Reporter: Abhishek Apoorva
> Assignee: Darran Lofthouse
> Fix For: 2.0.1.CR1
>
>
> Version : jboss-as-7.1.1.Final on windows server
> I am getting below mentioned strange issue intermittently while fetching
> Jboss JMX Mbean.
> Can anyone help me to find the real cause of the issue? Secong thing is why it is coming intermittently either it should come always or it should not come at all.
> JMXConnectorFactory.connect(serviceURL, environment);
> While executing above mentioned line system is throwing below mentioned exception.
> {noformat}
> May 08 02:30:53:375 [DC#0, jboss] java.lang.RuntimeException: Operation failed with status WAITING
> at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:216)
> at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:143)
> at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:94)
> at javax.management.remote.JMXConnectorFactory.connect(Unknown Source)
> at com.nimsoft.nimbus.probe.application.jboss.JmxConnection.createConnection(JmxConnection.java:68)
> at com.nimsoft.nimbus.probe.application.jsr160.Entity.createConnection(Entity.java:1772)
> at com.nimsoft.nimbus.probe.application.jsr160.Entity.getValue(Entity.java:1567)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract.processMonitor(Extract.java:1324)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract.processResource(Extract.java:1908)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract$DataCollector.run(Extract.java:1158)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (REMJMX-84) Jboss JMX: Operation failed with status WAITING
by Piotr Findeisen (JIRA)
[ https://issues.jboss.org/browse/REMJMX-84?page=com.atlassian.jira.plugin.... ]
Piotr Findeisen edited comment on REMJMX-84 at 2/16/15 5:01 AM:
----------------------------------------------------------------
The reason seems simple:
{code:java|title=org.jboss.remotingjmx.RemotingConnector.internalConnect}
// Now open the channel
final IoFuture<Channel> futureChannel = connection.openChannel(serviceName, OptionMap.EMPTY);
IoFuture.Status result = futureChannel.await(5, TimeUnit.SECONDS); // <-- 5 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}
As you see there is a hard-coded timeout of 5 seconds. I changed the timeout and now I'm able to connect. Apparently in some cases the connection takes up to 10 seconds! This is so even though the TCP-level connect takes 0.2s -- the 5 s timeout seems to cover _much_ more than just TCP connect.
was (Author: findepi):
The reason seems simple:
{code:java|title=org.jboss.remotingjmx.RemotingConnector.internalConnect}
// Now open the channel
final IoFuture<Channel> futureChannel = connection.openChannel(serviceName, OptionMap.EMPTY);
IoFuture.Status result = futureChannel.await(5, TimeUnit.SECONDS); // <-- 5 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}
As you see there is a hard-coded timeout of 5 seconds. I changed the timeout and now I'm able to connect. Apparently in some cases the connection takes up to 10 seconds! This is so even though the TCP-level connect takes 0.2s -- the 5 s timeout seems to cover _much_ more than just TCP connect.
(You can see my exact changes @ https://github.com/syncron/remoting-jmx/commit/32b35058230402b7b6a03ef1e3...)
> Jboss JMX: Operation failed with status WAITING
> ------------------------------------------------
>
> Key: REMJMX-84
> URL: https://issues.jboss.org/browse/REMJMX-84
> Project: Remoting JMX
> Issue Type: Bug
> Environment: jboss-as-7.1.1.Final on windows server
> Reporter: Abhishek Apoorva
> Assignee: Darran Lofthouse
> Fix For: 2.0.1.CR1
>
>
> Version : jboss-as-7.1.1.Final on windows server
> I am getting below mentioned strange issue intermittently while fetching
> Jboss JMX Mbean.
> Can anyone help me to find the real cause of the issue? Secong thing is why it is coming intermittently either it should come always or it should not come at all.
> JMXConnectorFactory.connect(serviceURL, environment);
> While executing above mentioned line system is throwing below mentioned exception.
> {noformat}
> May 08 02:30:53:375 [DC#0, jboss] java.lang.RuntimeException: Operation failed with status WAITING
> at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:216)
> at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:143)
> at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:94)
> at javax.management.remote.JMXConnectorFactory.connect(Unknown Source)
> at com.nimsoft.nimbus.probe.application.jboss.JmxConnection.createConnection(JmxConnection.java:68)
> at com.nimsoft.nimbus.probe.application.jsr160.Entity.createConnection(Entity.java:1772)
> at com.nimsoft.nimbus.probe.application.jsr160.Entity.getValue(Entity.java:1567)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract.processMonitor(Extract.java:1324)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract.processResource(Extract.java:1908)
> at com.nimsoft.nimbus.probe.application.extractbase.Extract$DataCollector.run(Extract.java:1158)
> at java.lang.Thread.run(Unknown Source)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4280) Component upgrade of Hibernate Validator to version 5.1.next.Final when HV-861 is fixed
by Hardy Ferentschik (JIRA)
[ https://issues.jboss.org/browse/WFLY-4280?page=com.atlassian.jira.plugin.... ]
Hardy Ferentschik commented on WFLY-4280:
-----------------------------------------
And you have no other modifications to the Wildfly container? I am still not able to re-produce this. I get:
{noformat}
/opt/java/wildfly/bin]$ ./standalone.sh
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /opt/java/wildfly
JAVA: /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/bin/java
JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
10:51:22,245 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final
10:51:27,014 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final
10:51:27,902 INFO [org.jboss.as] (MSC service thread 1-8) JBAS015899: WildFly 8.2.0.Final "Tweek" starting
10:51:37,091 INFO [org.jboss.as.server] (Controller Boot Thread) JBAS015888: Creating http management service using socket-binding (management-http)
10:51:37,333 INFO [org.xnio] (MSC service thread 1-5) XNIO version 3.3.0.Final
10:51:37,450 INFO [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.3.0.Final
10:51:37,569 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.
10:51:37,569 INFO [org.jboss.as.security] (ServerService Thread Pool -- 45) JBAS013171: Activating Security Subsystem
10:51:37,764 INFO [org.jboss.as.jsf] (ServerService Thread Pool -- 38) JBAS012615: Activated the following JSF Implementations: [main]
10:51:37,796 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 32) JBAS010280: Activating Infinispan subsystem.
10:51:37,797 INFO [org.jboss.as.webservices] (ServerService Thread Pool -- 48) JBAS015537: Activating WebServices Extension
10:51:37,831 INFO [org.jboss.as.security] (MSC service thread 1-7) JBAS013170: Current PicketBox version=4.0.21.Final
10:51:37,886 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 40) JBAS011800: Activating Naming Subsystem
10:51:38,046 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
10:51:38,356 INFO [org.jboss.as.connector.logging] (MSC service thread 1-6) JBAS010408: Starting JCA Subsystem (IronJacamar 1.1.9.Final)
10:51:38,622 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 47) JBAS017502: Undertow 1.1.0.Final starting
10:51:38,622 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS017502: Undertow 1.1.0.Final starting
10:51:39,768 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 27) JBAS010403: Deploying JDBC-compliant driver class org.h2.Driver (version 1.3)
10:51:40,015 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) JBAS010417: Started Driver service with driver-name = h2
10:51:40,658 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 47) JBAS017527: Creating file handler for path /opt/java/wildfly/welcome-content
10:51:40,664 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 4.0.6.Final
10:51:40,975 INFO [org.jboss.as.naming] (MSC service thread 1-4) JBAS011802: Starting Naming Service
10:51:40,976 INFO [org.jboss.as.mail.extension] (MSC service thread 1-6) JBAS015400: Bound mail session [java:jboss/mail/Default]
10:51:41,226 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS017525: Started server default-server.
10:51:41,398 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) JBAS017531: Host default-host starting
10:51:42,310 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) JBAS017519: Undertow HTTP listener default listening on /127.0.0.1:8080
10:51:43,638 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
10:51:43,708 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-2) JBAS015012: Started FileSystemDeploymentService for directory /opt/java/wildfly/standalone/deployments
10:51:43,856 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "hv-861-1.0-SNAPSHOT.jar" (runtime-name: "hv-861-1.0-SNAPSHOT.jar")
10:51:45,947 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016002: Processing weld deployment hv-861-1.0-SNAPSHOT.jar
10:51:46,344 INFO [org.jboss.ws.common.management] (MSC service thread 1-7) JBWS022052: Starting JBoss Web Services - Stack CXF Server 4.3.2.Final
10:51:46,353 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-4) HV000001: Hibernate Validator 5.1.3.Final
10:51:46,694 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016005: Starting Services for CDI deployment: hv-861-1.0-SNAPSHOT.jar
10:51:46,832 INFO [org.jboss.weld.Version] (MSC service thread 1-5) WELD-000900: 2.2.6 (Final)
10:51:46,898 INFO [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016008: Starting weld service for deployment hv-861-1.0-SNAPSHOT.jar
10:51:48,823 INFO [org.jboss.as.server] (ServerService Thread Pool -- 28) JBAS018559: Deployed "hv-861-1.0-SNAPSHOT.jar" (runtime-name : "hv-861-1.0-SNAPSHOT.jar")
10:51:48,883 INFO [org.jboss.as] (Controller Boot Thread) JBAS015961: Http management interface listening on http://127.0.0.1:9990/management
10:51:48,884 INFO [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
10:51:48,885 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.2.0.Final "Tweek" started in 29171ms - Started 225 of 280 services (90 services are lazy, passive or on-demand)
{noformat}
The same for the HotSpot 1.8 JVM. The only difference I can see now is that you are using the OpenJDK. If it is a VM based problem, it would also explain, why we have not been able to re-produce it. I will try with OpenJDK. Any chance you could try a different JVM as well?
> Component upgrade of Hibernate Validator to version 5.1.next.Final when HV-861 is fixed
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-4280
> URL: https://issues.jboss.org/browse/WFLY-4280
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Fedora 21, OpenJDK 1.8.0_25-b18.
> Reporter: Juan Hernández
> Assignee: Scott Marlow
> Attachments: hv-861.tar.gz
>
>
> The version of Hibernate Validator included in WildFly 8.1 and 8.2 throws an {{ArrayIndexOutOfBounds}} exception when deploying some applications. This is already reported in the Hibernate Validator JIRA:
> https://hibernate.atlassian.net/browse/HV-861
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-2391) Wildfly caches content in exploded mode, breaking developer productivity
by Gunnar Grim (JIRA)
[ https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin.... ]
Gunnar Grim commented on WFLY-2391:
-----------------------------------
Why does this bug have status "Resolved". I have this problem all the time on 8.2.0. Wildfly serves old html files even after undeploy, restart and redeploy. The undertow cache seems to survive everything I've thrown at it.
> Wildfly caches content in exploded mode, breaking developer productivity
> ------------------------------------------------------------------------
>
> Key: WFLY-2391
> URL: https://issues.jboss.org/browse/WFLY-2391
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Environment: MacOSX with JBossTools 4.1.1.Beta1
> Reporter: Xavier Coulon
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 8.0.0.CR1
>
> Attachments: jboss-as-kitchensink-html5-mobile.war.zip
>
>
> While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly 8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of my index.html file seemed to be cached by the server, although I used the "exploded content" deployment mode (since I published the content using the WildFly Server Adapter in JBoss Tools).
>
> I checked the actual content of the index.html in the deployments folder and it contained the latest changes, which means that the JBoss Tools Server Adapter is doing its job well ;-)
> I also tried to edit the index.html file directly in the deployments folder, and once again, I got no update in both Chrome and Firefox browsers.
>
> I checked in the "Network" tab of the browsers and could see that the server response for the index.html page had a "200 OK" status, which means that there's no browser caching involved.
> I tried to get the index.html page with cUrl and got the same old version, which definitely excludes a browser caching issue.
> At the end of the dat, this means that after a few changes, my browsers keep getting an old version of the deployed resources, which in turns means that I have to stop and restart the server to get the new content, and this is pretty bad in term of dev productivity.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4280) Component upgrade of Hibernate Validator to version 5.1.next.Final when HV-861 is fixed
by Juan Hernández (JIRA)
[ https://issues.jboss.org/browse/WFLY-4280?page=com.atlassian.jira.plugin.... ]
Juan Hernández commented on WFLY-4280:
--------------------------------------
What I did to reproduce this is building the example application and trying to manually deploy it, something like this:
{noformat}
cd hv-861
mvn clean package
cp target/hv-861-1.0-SNAPSHOT.jar /whatever/wildfly-8.2.0.Final/standalone/deployments/.
cd /whatever/wildfly-8.2.0.Final/bin
./standalone.sh
{noformat}
The result is this error message in the standard output:
{noformat}
10:16:32,198 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."hv-861-1.0-SNAPSHOT.jar".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."hv-861-1.0-SNAPSHOT.jar".WeldStartService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [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_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
java.lang.ArrayIndexOutOfBoundsException: 0
at org.hibernate.validator.internal.util.ExecutableHelper.instanceMethodParametersResolveToSameTypes(ExecutableHelper.java:141)
at org.hibernate.validator.internal.util.ExecutableHelper.overrides(ExecutableHelper.java:101)
at org.hibernate.validator.internal.cdi.ValidationExtension.replaceWithOverriddenOrInterfaceMethod(ValidationExtension.java:425)
at org.hibernate.validator.internal.cdi.ValidationExtension.determineConstrainedMethod(ValidationExtension.java:275)
at org.hibernate.validator.internal.cdi.ValidationExtension.determineConstrainedCallables(ValidationExtension.java:262)
at org.hibernate.validator.internal.cdi.ValidationExtension.processAnnotatedType(ValidationExtension.java:242)
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.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197)
at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169)
at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:158)
at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:230)
at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:373)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:91)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
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:745)
at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:204)
at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169)
at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:158)
at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:230)
at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:373)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:91)
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]
... 3 more
10:16:32,203 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "hv-861-1.0-SNAPSHOT.jar")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"hv-861-1.0-SNAPSHOT.jar\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"hv-861-1.0-SNAPSHOT.jar\".WeldStartService: Failed to start service
Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
Exception 0 :
java.lang.ArrayIndexOutOfBoundsException: 0
at org.hibernate.validator.internal.util.ExecutableHelper.instanceMethodParametersResolveToSameTypes(ExecutableHelper.java:141)
at org.hibernate.validator.internal.util.ExecutableHelper.overrides(ExecutableHelper.java:101)
at org.hibernate.validator.internal.cdi.ValidationExtension.replaceWithOverriddenOrInterfaceMethod(ValidationExtension.java:425)
at org.hibernate.validator.internal.cdi.ValidationExtension.determineConstrainedMethod(ValidationExtension.java:275)
at org.hibernate.validator.internal.cdi.ValidationExtension.determineConstrainedCallables(ValidationExtension.java:262)
at org.hibernate.validator.internal.cdi.ValidationExtension.processAnnotatedType(ValidationExtension.java:242)
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.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197)
at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169)
at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:158)
at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:230)
at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:373)
at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:91)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
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:745)
"}}
{noformat}
The annotation isn't relevant, as long as it triggers the call to {{org.hibernate.validator.internal.cdi.ValidationExtension.processAnnotatedType}}. If you prefer you can replace {{@Valid}} with {{@NotNull}}, or any constraint, the result is the same.
I tested this with OpenJDK 7 and OpenJDK 8.
I tested it with WildFly 8.2.0.Final "Tweek":
{noformat}
10:26:36,546 INFO [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.2.0.Final "Tweek" starting
{noformat}
Previously I tested it with 8.1.0 as well, and the result is the same.
> Component upgrade of Hibernate Validator to version 5.1.next.Final when HV-861 is fixed
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-4280
> URL: https://issues.jboss.org/browse/WFLY-4280
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Environment: Fedora 21, OpenJDK 1.8.0_25-b18.
> Reporter: Juan Hernández
> Assignee: Scott Marlow
> Attachments: hv-861.tar.gz
>
>
> The version of Hibernate Validator included in WildFly 8.1 and 8.2 throws an {{ArrayIndexOutOfBounds}} exception when deploying some applications. This is already reported in the Hibernate Validator JIRA:
> https://hibernate.atlassian.net/browse/HV-861
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4352) Servlet 3 - async-mode - onComplete not tirggered when JSP is dispatched
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4352?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-4352:
------------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
Component/s: Web (Undertow)
(was: Server)
> Servlet 3 - async-mode - onComplete not tirggered when JSP is dispatched
> ------------------------------------------------------------------------
>
> Key: WFLY-4352
> URL: https://issues.jboss.org/browse/WFLY-4352
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Reporter: Günther Grill
> Assignee: Stuart Douglas
> Labels: async, asynchronous, jsp, servlet
> Attachments: AsyncServlet.war
>
>
> When a JSP is dispatched in a Async-Servlet, the {{AsyncListener#onComplete}} is never triggered.
> {code:title=AsyncServlet.java|borderStyle=solid}
> @WebServlet(urlPatterns = { "/AsyncServlet" }, asyncSupported = true)
> public class AsyncServlet extends HttpServlet {
> public AsyncServlet() {
> super();
> }
> @Override
> protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
> res.setContentType("text/html");
> final AsyncContext ac;
> if (req.isAsyncStarted()) {
> ac = req.getAsyncContext();
> } else {
> ac = req.startAsync();
> }
> ac.setTimeout(5000);
> ac.addListener(new AsyncListener() {
> @Override
> public void onTimeout(AsyncEvent event) throws IOException {
> System.out.println("onTimeout");
> }
> @Override
> public void onStartAsync(AsyncEvent event) throws IOException {
> System.out.println("onStartAsync");
> }
> @Override
> public void onError(AsyncEvent event) throws IOException {
> System.out.println("onError");
> }
> @Override
> public void onComplete(AsyncEvent event) throws IOException {
> System.out.println("onComplete");
> }
> });
> System.out.println("Calling JSP...");
> ac.dispatch("/result.jsp");
> System.out.println("After JSP call");
> }
> }
> {code}
> {code:title=result.jsp|borderStyle=solid}
> <%@ page language="java" contentType="text/html; charset=ISO-8859-1"
> pageEncoding="ISO-8859-1"%>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
> <title>AsyncServletTest</title>
> </head>
> <body>
> <p>JSP Content</p>
> <%
> System.out.println("Start JSP");
> Thread.sleep(1000); // sleep 1 seconds
> String resp = (String)request.getAttribute("result");
> resp = resp + "<p>on JSP</p>";
> Thread.sleep(1000); // sleep 1 seconds
> System.out.println("End JSP");
> %>
> <p><%=resp%></p>
> </body>
> </html>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4345) ServiceNotFoundException for EJB referencing another EJB
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-4345?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-4345:
------------------------------
Fix Version/s: 9.0.0.Beta1
> ServiceNotFoundException for EJB referencing another EJB
> --------------------------------------------------------
>
> Key: WFLY-4345
> URL: https://issues.jboss.org/browse/WFLY-4345
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.Beta1
>
>
> I have an test with a client that uses two EJBs
> {noformat}
> class Client {
> @EJB(name="ejb/CDIUseCasesCMBEAN1")
> static CMBean1IF cmbean1;
> @EJB(name="ejb/CDIUseCasesCMBEAN2")
> static CMBean2IF cmbean2;
> }
> {noformat}
> The first EJB also references the second EJB:
> {noformat}
> @Stateless(name="CDIUseCasesCMBEAN1")
> @Remote({CMBean1IF.class})
> public class CMBean1 implements CMBean1IF {
> @EJB(name="ejb/CDIUseCasesCMBEAN2")
> CMBean2IF cmbean2;
> }
> @TransactionManagement(TransactionManagementType.CONTAINER)
> @Stateless(name="CDIUseCasesCMBEAN2")
> @Remote({CMBean2IF.class})
> public class CMBean2 implements CMBean2IF {
> }
> {noformat}
> When I deploy my application, the deployment fails with the error:
> {noformat}
> [javatest.batch] 11:39:17,668 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."cditestsusecases.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."cditestsusecases.ear".WeldStartService: Failed to start service
> [javatest.batch] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.4.Final.jar:1.2.4.Final]
> [javatest.batch] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> [javatest.batch] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> [javatest.batch] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> [javatest.batch] Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.deployment.subunit."cditestsusecases.ear"."cditestsusecases_ejb.jar".component.CDIUseCasesCMBEAN2.VIEW."com.sun.ts.tests.jms.ee20.cditests.usecases.CMBean2IF".REMOTE not found
> [javatest.batch] at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:669) [jboss-msc-1.2.4.Final.jar:1.2.4.Final]
> [javatest.batch] at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices.getComponentView(WeldEjbInjectionServices.java:149)
> [javatest.batch] at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices.handleServiceLookup(WeldEjbInjectionServices.java:124)
> [javatest.batch] at org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices.registerEjbInjectionPoint(WeldEjbInjectionServices.java:106)
> {noformat}
> As far as I can tell, the application is correctly built.
> The client jar contains the Client classes and the beans remote interfaces.
> The EJB jar contains the bean remote interfaces and classes.
> I debugged WildFly and fixed the issue by updating org.jboss.as.weld.services.bootstrap.WeldEjbInjectionServices#getComponentView to take into account that the EJB's view service may not be UP yet when the CMBean2IF EJB is injected into CMBean1.cmbean2 field:
> {noformat}
> private ComponentView getComponentView(ViewDescription viewDescription) {
> final ServiceController<?> controller = serviceRegistry.getService(viewDescription.getServiceName());
> if (controller == null) {
> return null;
> }
> return (ComponentView) controller.getValue();
> }
> {noformat}
> If there is no component view, the WeldEjbInjectionServices#handleServiceLookup will instead use a lazy resource.
> After that changes, my test passes fine.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months