[JBoss JIRA] (JASSIST-158) Method calls with a parameter of long[] or double[] are compiled to incorrect bytecode resulting in errors such as java.lang.VerifyError: ... Inconsistent args_size for opc_invokeinterface
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-158?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-158:
--------------------------------------
I think the patch appears correct, since an array on the operand stack should be represented by one unit (not two).
Section 2.6.2 in JVM spec (SE 7 edition):
{quote}
At any point in time, an operand stack has an associated depth, where a value of type long or double contributes two units to the depth and a value of any other type contributes one unit.
{quote}
> Method calls with a parameter of long[] or double[] are compiled to incorrect bytecode resulting in errors such as java.lang.VerifyError: ... Inconsistent args_size for opc_invokeinterface
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JASSIST-158
> URL: https://issues.jboss.org/browse/JASSIST-158
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA
> Reporter: Jens Deppe
> Assignee: Shigeru Chiba
>
> I believe this patch fixes the problem:
> Method calls with a parameter of long[] or double[] are compiled to incorrect bytecode. For example, the following piece of code...
> {code}
> long[] aLongArray;
> PdxWriter writer;
> ...
> writer.writeLongArray("aLongArray", aLongArray);
> {code}
> Produces code similar to this:
> {code}
> 13: aload_1
> 14: ldc #32; //String aLongArray
> 16: aload_0
> 17: getfield #35; //Field aLongArray:[J
> 20: invokeinterface #39, 4; //InterfaceMethod com/gemstone/gemfire/pdx/PdxWriter.writeLongArray:(Ljava/lang/String;[J)Lcom/gemstone/gemfire/pdx/PdxWriter;
> 25: pop
> {code}
> Following the code, it looks like getfield calculates an incorrect stackdepth when applied to a long[] or double[], resulting in an incorrect number of args applied to invokeinterface.
> The following patch seems to fix things.
> {code}
> Index: src/main/javassist/compiler/MemberCodeGen.java
> ===================================================================
> --- src/main/javassist/compiler/MemberCodeGen.java (revision 624)
> +++ src/main/javassist/compiler/MemberCodeGen.java (working copy)
> @@ -957,7 +957,7 @@
> else
> className = null;
>
> - boolean is2byte = (c == 'J' || c == 'D');
> + boolean is2byte = ((c == 'J' || c == 'D') && dim == 0);
> return is2byte;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1721) Access log support
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-1721:
---------------------------------
Summary: Access log support
Key: WFLY-1721
URL: https://issues.jboss.org/browse/WFLY-1721
Project: WildFly
Issue Type: Feature Request
Components: Web (Undertow)
Affects Versions: 8.0.0.Alpha3
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
Fix For: 8.0.0.Beta1
We need to expose access log configuration trough management.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1269) single jdbc driver deployed inside ear takes name of ear
by Paul Alesius (JIRA)
[ https://issues.jboss.org/browse/WFLY-1269?page=com.atlassian.jira.plugin.... ]
Paul Alesius edited comment on WFLY-1269 at 7/18/13 5:00 PM:
-------------------------------------------------------------
This doesn't work in Wildfly Alpha 3.
When deploying a jboss-ds.xml using <driver>myear.ear</dirver>, it worked in jboss as 7, but not anymore.
I've tried most combinations of myear.eardriver.jar myeardriverjar myeardriver.jar etc.
I don't know if the driver is found in the ear, there's no indication of this even with debug logging on.
Also, it's unclear how the driver version format is to be specified when the maven version is for example <version>9.2-1003-jdbc4</version>
Specifying it as <driver>myear.earpostgresql.jar</div> would be ideal as there won't be different versions in that same jar
was (Author: paul_alesius):
This doesn't work in Wildfly Alpha 3.
When deploying a jboss-ds.xml using <driver>myear.ear</dirver>, it worked in jboss as 7, but not anymore.
I've tried most combinations of myear.eardriver.jar myeardriverjar myeardriver.jar etc.
I don't know if the driver is found in the ear, there's no indication of this even with debug logging on.
Also, it's unclear how the driver version format is to be specified when the maven version is for example <version>9.2-1003-jdbc4</version>
> single jdbc driver deployed inside ear takes name of ear
> --------------------------------------------------------
>
> Key: WFLY-1269
> URL: https://issues.jboss.org/browse/WFLY-1269
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 8.0.0.Alpha1
> Reporter: Tom Eicher
> Assignee: Stefano Maestri
> Fix For: 8.0.0.Alpha1
>
>
> We need to always give service name for jdbdriver as
> {code}
> deploymentUnit.getName() + "_" + driverClassName + "_" + majorVersion +"_" + minorVersion
> {code}
> even if thre is only one driver in the deployment unit. Current behavior is to give just deploymentUnit name in case of only one driver in. The changes makes more clear/readable driver names.
> Original description was:
> Including a JDBC driver, in this case PostgreSQL, in an ear like
> {code}
> myapp.ear:
> lib/postgresql-9.1-901.jdbc4.jar
> {code}
> does deploy the driver:
> {code}
> 23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
> {code}
> however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
> but it's {{myapp_ear}}.
> (Seen in admin console, and this is the only value accepted in my -ds.xml file.)
> 1. JDBC driver service should pick name of innermost jar, not of containing ear
> 2. driver name (as to be used in datasource definition) should be logged with the log message above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1269) single jdbc driver deployed inside ear takes name of ear
by Paul Alesius (JIRA)
[ https://issues.jboss.org/browse/WFLY-1269?page=com.atlassian.jira.plugin.... ]
Paul Alesius edited comment on WFLY-1269 at 7/18/13 4:58 PM:
-------------------------------------------------------------
This doesn't work in Wildfly Alpha 3.
When deploying a jboss-ds.xml using <driver>myear.ear</dirver>, it worked in jboss as 7, but not anymore.
I've tried most combinations of myear.eardriver.jar myeardriverjar myeardriver.jar etc.
I don't know if the driver is found in the ear, there's no indication of this even with debug logging on.
Also, it's unclear how the driver version format is to be specified when the maven version is for example <version>9.2-1003-jdbc4</version>
was (Author: paul_alesius):
This doesn't work in Wildfly Alpha 3.
When deploying a jboss-ds.xml using <driver>myear.ear</dirver>, it worked in jboss as 7, but not anymore.
I've tried most combinations of myear.eardriver.jar myeardriverjar myeardriver.jar etc.
I don't know if the driver is found in the ear, there's no indication of this even with debug logging on.
> single jdbc driver deployed inside ear takes name of ear
> --------------------------------------------------------
>
> Key: WFLY-1269
> URL: https://issues.jboss.org/browse/WFLY-1269
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 8.0.0.Alpha1
> Reporter: Tom Eicher
> Assignee: Stefano Maestri
> Fix For: 8.0.0.Alpha1
>
>
> We need to always give service name for jdbdriver as
> {code}
> deploymentUnit.getName() + "_" + driverClassName + "_" + majorVersion +"_" + minorVersion
> {code}
> even if thre is only one driver in the deployment unit. Current behavior is to give just deploymentUnit name in case of only one driver in. The changes makes more clear/readable driver names.
> Original description was:
> Including a JDBC driver, in this case PostgreSQL, in an ear like
> {code}
> myapp.ear:
> lib/postgresql-9.1-901.jdbc4.jar
> {code}
> does deploy the driver:
> {code}
> 23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
> {code}
> however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
> but it's {{myapp_ear}}.
> (Seen in admin console, and this is the only value accepted in my -ds.xml file.)
> 1. JDBC driver service should pick name of innermost jar, not of containing ear
> 2. driver name (as to be used in datasource definition) should be logged with the log message above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1269) single jdbc driver deployed inside ear takes name of ear
by Paul Alesius (JIRA)
[ https://issues.jboss.org/browse/WFLY-1269?page=com.atlassian.jira.plugin.... ]
Paul Alesius edited comment on WFLY-1269 at 7/18/13 4:56 PM:
-------------------------------------------------------------
This doesn't work in Wildfly Alpha 3.
When deploying a jboss-ds.xml using <driver>myear.ear</dirver>, it worked in jboss as 7, but not anymore.
I've tried most combinations of myear.eardriver.jar myeardriverjar myeardriver.jar etc.
I don't know if the driver is found in the ear, there's no indication of this even with debug logging on.
was (Author: paul_alesius):
This doesn't work in Wildfly Alpha 3.
When deploying a jboss-ds.xml using <driver>myear.ear</dirver>, it worked in jboss as 7, but not anymore.
I've tried most combinations of myear.eardriver.jar myeardriverjar myeardriver.jar etc.
> single jdbc driver deployed inside ear takes name of ear
> --------------------------------------------------------
>
> Key: WFLY-1269
> URL: https://issues.jboss.org/browse/WFLY-1269
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 8.0.0.Alpha1
> Reporter: Tom Eicher
> Assignee: Stefano Maestri
> Fix For: 8.0.0.Alpha1
>
>
> We need to always give service name for jdbdriver as
> {code}
> deploymentUnit.getName() + "_" + driverClassName + "_" + majorVersion +"_" + minorVersion
> {code}
> even if thre is only one driver in the deployment unit. Current behavior is to give just deploymentUnit name in case of only one driver in. The changes makes more clear/readable driver names.
> Original description was:
> Including a JDBC driver, in this case PostgreSQL, in an ear like
> {code}
> myapp.ear:
> lib/postgresql-9.1-901.jdbc4.jar
> {code}
> does deploy the driver:
> {code}
> 23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
> {code}
> however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
> but it's {{myapp_ear}}.
> (Seen in admin console, and this is the only value accepted in my -ds.xml file.)
> 1. JDBC driver service should pick name of innermost jar, not of containing ear
> 2. driver name (as to be used in datasource definition) should be logged with the log message above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1269) single jdbc driver deployed inside ear takes name of ear
by Paul Alesius (JIRA)
[ https://issues.jboss.org/browse/WFLY-1269?page=com.atlassian.jira.plugin.... ]
Paul Alesius commented on WFLY-1269:
------------------------------------
This doesn't work in Wildfly Alpha 3.
When deploying a jboss-ds.xml using <driver>myear.ear</dirver>, it worked in jboss as 7, but not anymore.
I've tried most combinations of myear.eardriver.jar myeardriverjar myeardriver.jar etc.
> single jdbc driver deployed inside ear takes name of ear
> --------------------------------------------------------
>
> Key: WFLY-1269
> URL: https://issues.jboss.org/browse/WFLY-1269
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Affects Versions: 8.0.0.Alpha1
> Reporter: Tom Eicher
> Assignee: Stefano Maestri
> Fix For: 8.0.0.Alpha1
>
>
> We need to always give service name for jdbdriver as
> {code}
> deploymentUnit.getName() + "_" + driverClassName + "_" + majorVersion +"_" + minorVersion
> {code}
> even if thre is only one driver in the deployment unit. Current behavior is to give just deploymentUnit name in case of only one driver in. The changes makes more clear/readable driver names.
> Original description was:
> Including a JDBC driver, in this case PostgreSQL, in an ear like
> {code}
> myapp.ear:
> lib/postgresql-9.1-901.jdbc4.jar
> {code}
> does deploy the driver:
> {code}
> 23:37:28,118 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-1) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.1)
> {code}
> however the service name is not {{postgresql_9_1_901_jdbc4_jar}} as expected,
> but it's {{myapp_ear}}.
> (Seen in admin console, and this is the only value accepted in my -ds.xml file.)
> 1. JDBC driver service should pick name of innermost jar, not of containing ear
> 2. driver name (as to be used in datasource definition) should be logged with the log message above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (JGRP-1661) AUTH bypasses join requests without auth_headers
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1661?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1661:
---------------------------
Fix Version/s: 3.3.4
3.4
> AUTH bypasses join requests without auth_headers
> ------------------------------------------------
>
> Key: JGRP-1661
> URL: https://issues.jboss.org/browse/JGRP-1661
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.3
> Reporter: Sergey Tumashov
> Assignee: Bela Ban
> Fix For: 3.3.4, 3.4
>
>
> The cluster coordinator allows new members to join the cluster if their join requests do not contain auth headers.
> A simple test case would involve two nodes. One node should be configured to use a protocol stack with AUTH. The other node should use the same stack but with AUTH excluded. The node that uses AUTH needs to be brought up first so it can become cluster coordinator. The second node will now successfully join the cluster even though it does not send any auth tokens along with its join requests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1719) ClassCastException on clustered deployment
by Matthias Berndt (JIRA)
[ https://issues.jboss.org/browse/WFLY-1719?page=com.atlassian.jira.plugin.... ]
Matthias Berndt updated WFLY-1719:
----------------------------------
Attachment: cluster-demo.war
> ClassCastException on clustered deployment
> ------------------------------------------
>
> Key: WFLY-1719
> URL: https://issues.jboss.org/browse/WFLY-1719
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha3
> Environment: windows; oracle jdk 1.7.0_17
> Reporter: Matthias Berndt
> Assignee: Paul Ferraro
> Attachments: cluster-demo.war
>
>
> In a windows 7 environment the cluster replication for a clustered web archive deployed in a server with _full-ha_-profile fails with a class cast exception.
> {code}
> 21:00:03,514 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) JBAS015876: Starting deployment of "cd" (runtime-name: "cd.war")
> 21:00:05,179 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,179 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-4) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,182 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-4) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,182 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,183 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,184 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-3) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> 21:00:05,228 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 61) ISPN000078: Starting JGroups Channel
> 21:00:05,240 INFO [stdout] (ServerService Thread Pool -- 61)
> 21:00:05,240 INFO [stdout] (ServerService Thread Pool -- 61) -------------------------------------------------------------------
> 21:00:05,240 INFO [stdout] (ServerService Thread Pool -- 61) GMS: address=master:server-three/web, cluster=web, physical address=127.0.0.1:55450
> 21:00:05,240 INFO [stdout] (ServerService Thread Pool -- 61) -------------------------------------------------------------------
> 21:00:07,251 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 61) ISPN000094: Received new cluster view: [master:server-three/web|0] [master:server-three/web]
> 21:00:07,317 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 61) ISPN000079: Cache local address is master:server-three/web, physical addresses are [127.0.0.1:55450]
> 21:00:07,326 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 61) ISPN000128: Infinispan version: Infinispan 'Tactical Nuclear Penguin' 5.3.0.Final
> 21:00:07,492 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 61) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 21:00:07,492 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 65) ISPN000031: MBeans were successfully registered to the platform MBean server.
> 21:00:07,505 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 65) JBAS010281: Started default-host/cd cache from web container
> 21:00:07,505 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 61) JBAS010281: Started repl cache from web container
> 21:00:07,637 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) JBAS018210: Register web context: /cd
> 21:00:07,675 INFO [org.jboss.as.server] (host-controller-connection-threads - 1) JBAS018559: Deployed "cd" (runtime-name : "cd.war")
> 21:00:57,609 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.ClassCastException: org.infinispan.transaction.TransactionTable cannot be cast to org.infinispan.transaction.xa.XaTransactionTable
> at org.infinispan.transaction.xa.TransactionXaAdapter.<init>(TransactionXaAdapter.java:100)
> at org.infinispan.CacheImpl.getXAResource(CacheImpl.java:875)
> at org.infinispan.AbstractDelegatingAdvancedCache.getXAResource(AbstractDelegatingAdvancedCache.java:158)
> at org.jboss.as.clustering.infinispan.subsystem.CacheService$InfinispanXAResourceRecovery.getXAResources(CacheService.java:112)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:503) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:159) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> {code}
> The exception is reoccuring every ten seconds.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (JGRP-1661) AUTH bypasses join requests without auth_headers
by Sergey Tumashov (JIRA)
[ https://issues.jboss.org/browse/JGRP-1661?page=com.atlassian.jira.plugin.... ]
Sergey Tumashov updated JGRP-1661:
----------------------------------
Issue Type: Bug (was: Feature Request)
> AUTH bypasses join requests without auth_headers
> ------------------------------------------------
>
> Key: JGRP-1661
> URL: https://issues.jboss.org/browse/JGRP-1661
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.3
> Reporter: Sergey Tumashov
> Assignee: Bela Ban
>
> The cluster coordinator allows new members to join the cluster if their join requests do not contain auth headers.
> A simple test case would involve two nodes. One node should be configured to use a protocol stack with AUTH. The other node should use the same stack but with AUTH excluded. The node that uses AUTH needs to be brought up first so it can become cluster coordinator. The second node will now successfully join the cluster even though it does not send any auth tokens along with its join requests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months