January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3554) ejb-jar.xml interceptor-binding does not accept "*"

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3554?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3554: ----------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1114061|https://bugzilla.redhat.com/show_bug.cgi?id=1114061] from POST to CLOSED > ejb-jar.xml interceptor-binding does not accept "*" > --------------------------------------------------- > > Key: WFLY-3554 > URL: https://issues.jboss.org/browse/WFLY-3554 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.1.0.Final > Reporter: Wolf-Dieter Fink > Assignee: Bartosz Baranowski > Fix For: 8.2.0.Final, 9.0.0.Alpha1 > > > From the ejb3.1 specification (JSR 318) chapter 12.7 Specification of Interceptors in the Deployment Descriptor: > "" > In the interceptor-binding element, the target-name element must be the name of one of > the enterprise beans contained in the ejb-jar or the wildcard value “*”. > "" > But the "*" as ejb-name is ignored, only a bean name will result in binding the interceptor during deployment -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-523) wildfly-init-redhat.sh should touch /var/lock/subsys/wildfly for properly shutdown

by Kohei Nozaki (JIRA)

[ https://issues.jboss.org/browse/WFCORE-523?page=com.atlassian.jira.plugin... ] Kohei Nozaki updated WFCORE-523: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/455 > wildfly-init-redhat.sh should touch /var/lock/subsys/wildfly for properly shutdown > ---------------------------------------------------------------------------------- > > Key: WFCORE-523 > URL: https://issues.jboss.org/browse/WFCORE-523 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Affects Versions: 1.0.0.Alpha16 > Environment: CentOS 6.6 > Reporter: Kohei Nozaki > Assignee: Tomaz Cerar > > When I shutdown CentOS, it doesn't wait for complete shutdown of WildFly. I see that server.log doesn't end with `JBAS015950: WildFly 8.2.0.Final "Tweek" stopped in 437ms` at shutdown of CentOS. also there's no message which indicates that processing of WildFly shutdown (e.g. Stopping wildfly...). it seems like that shutdown script was not invoked and CentOS killed the process of WildFly. > It's not good for embedded database that requires shutdown properly. I have a embedded Derby within WildFly and it needs properly shutdown for every time to avoid data corruption. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-523) wildfly-init-redhat.sh should touch /var/lock/subsys/wildfly for properly shutdown

by Kohei Nozaki (JIRA)

Kohei Nozaki created WFCORE-523: ----------------------------------- Summary: wildfly-init-redhat.sh should touch /var/lock/subsys/wildfly for properly shutdown Key: WFCORE-523 URL: https://issues.jboss.org/browse/WFCORE-523 Project: WildFly Core Issue Type: Enhancement Components: Scripts Affects Versions: 1.0.0.Alpha16 Environment: CentOS 6.6 Reporter: Kohei Nozaki Assignee: Tomaz Cerar When I shutdown CentOS, it doesn't wait for complete shutdown of WildFly. I see that server.log doesn't end with `JBAS015950: WildFly 8.2.0.Final "Tweek" stopped in 437ms` at shutdown of CentOS. also there's no message which indicates that processing of WildFly shutdown (e.g. Stopping wildfly...). it seems like that shutdown script was not invoked and CentOS killed the process of WildFly. It's not good for embedded database that requires shutdown properly. I have a embedded Derby within WildFly and it needs properly shutdown for every time to avoid data corruption. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-241) VerifyError: Expecting a stackmap frame - Switch case statement Java 7

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-241?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-241: --------------------------------------- I fixed the bug of dead-code treatment. Also changed insertAfter() so that it will not generate dead code. > VerifyError: Expecting a stackmap frame - Switch case statement Java 7 > ---------------------------------------------------------------------- > > Key: JASSIST-241 > URL: https://issues.jboss.org/browse/JASSIST-241 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.19.0-GA > Environment: jdk7 > Reporter: Patson Luk > Assignee: Shigeru Chiba > Fix For: 3.20.0-GA > > > This could be a duplicate of issue 215 and 205. > Tested it on the master (3.19.0-GA) with java 7. Running the below class > {code} > import java.util.Random; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtMethod; > public class TestDriver { > public static void main(String[] args) throws Exception { > ClassPool pool = ClassPool.getDefault(); > CtClass cc = pool.get("TestClass"); > > CtMethod testMethod = cc.getMethod("test", "(Ljava/lang/Object;)V"); > testMethod.insertAfter("System.out.println(\"inserted!\");"); > cc.toClass(); > //invoke it > TestClass.test(new Object()); > } > } > class TestClass { > public static void test(Object o) { > //part 1 > if (o == null) { > return; > } > //part 2 > int oper = new Random().nextInt(); > switch (oper) { > case 1: > break; > } > } > } > {code} > > Triggers error message as below: > {quote} > Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method TestClass.test(Ljava/lang/Object;)V at offset 1 > at TestDriver.main(TestDriver.java:19) > {quote} > *Please take note that:* > # This is observed on Java 7. When the same code is run on Java 6, it is fine > # Both the "part 1" - return statement (commented in the code above) and "part 2" - switch/case statement have to be there to trigger the error. If either of those are commented out, then the code runs fine -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-241) VerifyError: Expecting a stackmap frame - Switch case statement Java 7

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-241?page=com.atlassian.jira.plugi... ] Shigeru Chiba closed JASSIST-241. --------------------------------- > VerifyError: Expecting a stackmap frame - Switch case statement Java 7 > ---------------------------------------------------------------------- > > Key: JASSIST-241 > URL: https://issues.jboss.org/browse/JASSIST-241 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.19.0-GA > Environment: jdk7 > Reporter: Patson Luk > Assignee: Shigeru Chiba > Fix For: 3.20.0-GA > > > This could be a duplicate of issue 215 and 205. > Tested it on the master (3.19.0-GA) with java 7. Running the below class > {code} > import java.util.Random; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtMethod; > public class TestDriver { > public static void main(String[] args) throws Exception { > ClassPool pool = ClassPool.getDefault(); > CtClass cc = pool.get("TestClass"); > > CtMethod testMethod = cc.getMethod("test", "(Ljava/lang/Object;)V"); > testMethod.insertAfter("System.out.println(\"inserted!\");"); > cc.toClass(); > //invoke it > TestClass.test(new Object()); > } > } > class TestClass { > public static void test(Object o) { > //part 1 > if (o == null) { > return; > } > //part 2 > int oper = new Random().nextInt(); > switch (oper) { > case 1: > break; > } > } > } > {code} > > Triggers error message as below: > {quote} > Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method TestClass.test(Ljava/lang/Object;)V at offset 1 > at TestDriver.main(TestDriver.java:19) > {quote} > *Please take note that:* > # This is observed on Java 7. When the same code is run on Java 6, it is fine > # Both the "part 1" - return statement (commented in the code above) and "part 2" - switch/case statement have to be there to trigger the error. If either of those are commented out, then the code runs fine -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-241) VerifyError: Expecting a stackmap frame - Switch case statement Java 7

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-241?page=com.atlassian.jira.plugi... ] Shigeru Chiba resolved JASSIST-241. ----------------------------------- Fix Version/s: 3.20.0-GA Resolution: Done > VerifyError: Expecting a stackmap frame - Switch case statement Java 7 > ---------------------------------------------------------------------- > > Key: JASSIST-241 > URL: https://issues.jboss.org/browse/JASSIST-241 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.19.0-GA > Environment: jdk7 > Reporter: Patson Luk > Assignee: Shigeru Chiba > Fix For: 3.20.0-GA > > > This could be a duplicate of issue 215 and 205. > Tested it on the master (3.19.0-GA) with java 7. Running the below class > {code} > import java.util.Random; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtMethod; > public class TestDriver { > public static void main(String[] args) throws Exception { > ClassPool pool = ClassPool.getDefault(); > CtClass cc = pool.get("TestClass"); > > CtMethod testMethod = cc.getMethod("test", "(Ljava/lang/Object;)V"); > testMethod.insertAfter("System.out.println(\"inserted!\");"); > cc.toClass(); > //invoke it > TestClass.test(new Object()); > } > } > class TestClass { > public static void test(Object o) { > //part 1 > if (o == null) { > return; > } > //part 2 > int oper = new Random().nextInt(); > switch (oper) { > case 1: > break; > } > } > } > {code} > > Triggers error message as below: > {quote} > Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method TestClass.test(Ljava/lang/Object;)V at offset 1 > at TestDriver.main(TestDriver.java:19) > {quote} > *Please take note that:* > # This is observed on Java 7. When the same code is run on Java 6, it is fine > # Both the "part 1" - return statement (commented in the code above) and "part 2" - switch/case statement have to be there to trigger the error. If either of those are commented out, then the code runs fine -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-697) Report an error when a declared type extends the wrong type

by Davide Sottara (JIRA)

Davide Sottara created DROOLS-697: ------------------------------------- Summary: Report an error when a declared type extends the wrong type Key: DROOLS-697 URL: https://issues.jboss.org/browse/DROOLS-697 Project: Drools Issue Type: Enhancement Affects Versions: 6.2.0.CR4, 6.1.0.Final, 6.0.1.Final, 5.6.0.Final, 5.5.0.Final Reporter: Davide Sottara Assignee: Davide Sottara Priority: Minor Fix For: 6.2.0.Final Declared pojos should extend regular classes, while declared traits should extend interfaces. The bean creation process does not enforce such a type check, possibly resulting in serious exceptions -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JASSIST-241) VerifyError: Expecting a stackmap frame - Switch case statement Java 7

by Shigeru Chiba (JIRA)

[ https://issues.jboss.org/browse/JASSIST-241?page=com.atlassian.jira.plugi... ] Shigeru Chiba commented on JASSIST-241: --------------------------------------- I think your problem analysis is right. Thanks, it helps bug fixing lots! > VerifyError: Expecting a stackmap frame - Switch case statement Java 7 > ---------------------------------------------------------------------- > > Key: JASSIST-241 > URL: https://issues.jboss.org/browse/JASSIST-241 > Project: Javassist > Issue Type: Bug > Affects Versions: 3.19.0-GA > Environment: jdk7 > Reporter: Patson Luk > Assignee: Shigeru Chiba > > This could be a duplicate of issue 215 and 205. > Tested it on the master (3.19.0-GA) with java 7. Running the below class > {code} > import java.util.Random; > import javassist.ClassPool; > import javassist.CtClass; > import javassist.CtMethod; > public class TestDriver { > public static void main(String[] args) throws Exception { > ClassPool pool = ClassPool.getDefault(); > CtClass cc = pool.get("TestClass"); > > CtMethod testMethod = cc.getMethod("test", "(Ljava/lang/Object;)V"); > testMethod.insertAfter("System.out.println(\"inserted!\");"); > cc.toClass(); > //invoke it > TestClass.test(new Object()); > } > } > class TestClass { > public static void test(Object o) { > //part 1 > if (o == null) { > return; > } > //part 2 > int oper = new Random().nextInt(); > switch (oper) { > case 1: > break; > } > } > } > {code} > > Triggers error message as below: > {quote} > Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method TestClass.test(Ljava/lang/Object;)V at offset 1 > at TestDriver.main(TestDriver.java:19) > {quote} > *Please take note that:* > # This is observed on Java 7. When the same code is run on Java 6, it is fine > # Both the "part 1" - return statement (commented in the code above) and "part 2" - switch/case statement have to be there to trigger the error. If either of those are commented out, then the code runs fine -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-505) Fix double redeployment due to .failed file and a artifact with newer timestamp.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-505?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-505: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1169239 > Fix double redeployment due to .failed file and a artifact with newer timestamp. > -------------------------------------------------------------------------------- > > Key: WFCORE-505 > URL: https://issues.jboss.org/browse/WFCORE-505 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha15 > Reporter: Chao Wang > Assignee: Chao Wang > Fix For: 1.0.0.Alpha16 > > > Issue found and described in https://bugzilla.redhat.com/show_bug.cgi?id=1169239 > steps to reproduce: > 1. deploy a "Test.war" > 2. Change something in "Test.war" to fail it. > 3. "Test.war.failed" file will be created. > 4. stop JBoss EAP. > 5. Revert the changes done in "Test.war" so that it will deploy successfully. > 6. Now there are two files ("Test.war.failed" and "Test.war", due to correction, Test.war must have a newer timestamp than Test.war.failed)in deployment directory. > 7. Restart JBoss EAP, it will fail with below Error : > The problem happens as a result of redundant redeployment in next reboot. During servert reboot, it will try to redeploy the application due to found .failed file, it also will try to redeploy same application because Test.war has a newer timestamp to see the problem. This will cause server startup failure as: > {noformat} > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 18) JBAS014613: Operation ("add") failed - address: ([("deployment" => "Test.war")]) - failure description: "JBAS014803: Duplicate resource [(\"deployment\" => \"Test.war\")] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-522) BlockingNotificationMBeanServer will NPE if resolvedDomain or expressionsDomain are not configured

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-522?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-522: ------------------------------------------------ Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1185496|https://bugzilla.redhat.com/show_bug.cgi?id=1185496] from NEW to POST > BlockingNotificationMBeanServer will NPE if resolvedDomain or expressionsDomain are not configured > -------------------------------------------------------------------------------------------------- > > Key: WFCORE-522 > URL: https://issues.jboss.org/browse/WFCORE-522 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha16 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > If the jmx subsystem <expose-resolved-model/> and/or <expose-expression-model/> settings are not configured, but <remoting-connector/> is BlockingNotificationMBeanServer will throw NPEs in isInExposedModelControllerDomains due to passing null into java.util.regex.Pattern.matcher(...). > Simply null checks will fix the problem. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015