March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-416) Queries do not work with events

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-416?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-416: ------------------------------------------------ Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1063805|https://bugzilla.redhat.com/show_bug.cgi?id=1063805] from MODIFIED to ON_QA > Queries do not work with events > ------------------------------- > > Key: DROOLS-416 > URL: https://issues.jboss.org/browse/DROOLS-416 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Final > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.1.0.Beta1 > > -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-393) Trait Hierarchy is not rebuilt correctly when merging packages

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-393?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-393: ------------------------------------------------ Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1063803|https://bugzilla.redhat.com/show_bug.cgi?id=1063803] from MODIFIED to ON_QA > Trait Hierarchy is not rebuilt correctly when merging packages > -------------------------------------------------------------- > > Key: DROOLS-393 > URL: https://issues.jboss.org/browse/DROOLS-393 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final, 6.0.0.Final, 6.0.1.Final > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Critical > Fix For: 5.5.1.Final, 6.1.0.Final > > -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-421) EvaluatorWrapper does not resolve the right handle correctly

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-421?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-421: ------------------------------------------------ Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1063809|https://bugzilla.redhat.com/show_bug.cgi?id=1063809] from MODIFIED to ON_QA > EvaluatorWrapper does not resolve the right handle correctly > ------------------------------------------------------------ > > Key: DROOLS-421 > URL: https://issues.jboss.org/browse/DROOLS-421 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.1.Final, 6.0.0.Final, 6.0.1.Final, 6.1.0.Beta1 > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.1.0.Beta1 > > > The EvaluatorWrapper tries to look up the right handle from the WM, but there may be cases (e.g. when the right input comes from a FROM node) > where the handle is not in the WM, causing a NPE. This causes the right handle to be null, or to be resolved incorrectly. Evaluations are then inconsistent. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3042) There should be a warning logged if the default value of node identifier has not been changed.

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-3042?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on WFLY-3042: ------------------------------------- What I meant, is that we _want_ to support different servers assuming the identity. There is a concept with Narayana that you can run the transaction manager on any machine and point it at an object store (e.g. jdbc one) and give it an identifier to take over from an old server. Narayana itself is pluggable, i.e. it exposes a setXaNodeName method that clients (e.g. subsystem) are free to pass in what they like. The subsystem itself is currently only pluggable in so much as it supports a single implementation that obtains the value to use from the standalone.xml. It would be possible to alter the subsystem to use the IP address etc but as I say, when it boots up on a different machine it will have a different node name so wouldn't take over from the old server. Happy to alter the subsystem but I am not really sure its a good idea to use the IP/port as the ID for the reason I mentioned above. In terms of the alternative (a uuid), I mentioned the reason I was worried to use something random is in case it is lost. Suggestions? > There should be a warning logged if the default value of node identifier has not been changed. > ------------------------------------------------------------------------------------------------ > > Key: WFLY-3042 > URL: https://issues.jboss.org/browse/WFLY-3042 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Transactions > Affects Versions: 8.0.0.Final > Environment: JBoss EAP 6.x > Reporter: Tom Ross > Assignee: Gytis Trikleris > > JBoss EAP instance is using the value of node identifier to identify XA transactions that belong to it. By default this value is set to 1. Now days in most environments there will be multiple JBoss instances sharing XA resources there for it is necessary to set the value of node identifier to a unique value for each instance. This is something that most end users fail to perform. Therefor it would be helpful if a warning message was logged at startup telling the user to do it. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3052) Upgrade Hibernate Validator to 5.1.0.Final

by Hardy Ferentschik (JIRA)

[ https://issues.jboss.org/browse/WFLY-3052?page=com.atlassian.jira.plugin.... ] Hardy Ferentschik updated WFLY-3052: ------------------------------------ Description: Hibernate Validator 5.1.0.Final contains several performance improvements as well as a lower memory footprint. It also fixes a {{NullPointerException}} during server shutdown ([HV-865|https://hibernate.atlassian.net/browse/HV-865]). (was: Hibernate Validator 5.1.0.Final contains several performance improvements as well as a lower memory footprint. It also fixes a {{NullPointerException}} during server shutdown ([HV-865|https://hibernate.atlassian.net/browse/HV-865]) > Upgrade Hibernate Validator to 5.1.0.Final > ------------------------------------------ > > Key: WFLY-3052 > URL: https://issues.jboss.org/browse/WFLY-3052 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Hardy Ferentschik > Assignee: Hardy Ferentschik > Fix For: 8.0.1.Final > > > Hibernate Validator 5.1.0.Final contains several performance improvements as well as a lower memory footprint. It also fixes a {{NullPointerException}} during server shutdown ([HV-865|https://hibernate.atlassian.net/browse/HV-865]). -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3052) Upgrade Hibernate Validator to 5.1.0.Final

by Hardy Ferentschik (JIRA)

Hardy Ferentschik created WFLY-3052: --------------------------------------- Summary: Upgrade Hibernate Validator to 5.1.0.Final Key: WFLY-3052 URL: https://issues.jboss.org/browse/WFLY-3052 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 8.0.1.Final Hibernate Validator 5.1.0.Final contains several performance improvements as well as a lower memory footprint. It also fixes a {{NullPointerException}} during server shutdown ([HV-865|https://hibernate.atlassian.net/browse/HV-865] -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBWEB-290) Optimize string literals inside jsp expressions

by Remy Maucherat (JIRA)

[ https://issues.jboss.org/browse/JBWEB-290?page=com.atlassian.jira.plugin.... ] Remy Maucherat commented on JBWEB-290: -------------------------------------- This is not going to get fixed or looked at as this is scriplet = a Java code fragment. It is equivalent to writing the same Java code in a Servlet. > Optimize string literals inside jsp expressions > ------------------------------------------------ > > Key: JBWEB-290 > URL: https://issues.jboss.org/browse/JBWEB-290 > Project: JBoss Web > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Tomcat > Affects Versions: JBossWeb-3.0.0.Final > Reporter: John O'Hara > Assignee: Remy Maucherat > > After setting genStringAsCharArray=true, we continue to see StringBuilder concatenating string literals for each jsp request for some of our jsp pages; instead of creating a static char[]. > This occurs when a string literal is included in a jsp expression, e.g.; > <%="<INPUT type=\"hidden\" name=\"name\" value=\"" + obj.getName() + "\">"%> > Is it possible to identify string literals inside expressions during the tokenization phase of parsing jsp pages in apache jasper and treat them as text nodes so that the apache jasper generator can apply the same optimizations as string literals outside the jsp expression? -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2920) StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2920: ----------------------------------------------- Osamu Nagano <onagano(a)redhat.com> changed the Status of [bug 1064644|https://bugzilla.redhat.com/show_bug.cgi?id=1064644] from ASSIGNED to POST > StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject > -------------------------------------------------------------------------------------------------- > > Key: WFLY-2920 > URL: https://issues.jboss.org/browse/WFLY-2920 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: IIOP > Affects Versions: 8.0.0.Final > Reporter: Osamu Nagano > Assignee: Stefan Guilhen > Attachments: td.dump > > > Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}. Here is the stack trace from the attached thread dump. > {code} > "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000] > java.lang.Thread.State: RUNNABLE > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116) > at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177) > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116) > at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > ... > at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177) > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > Locked ownable synchronizers: > - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker) > {code} > The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost. The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment. > The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}. It is reproducible by manually controlling a thread context switch using a debugger. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-2920) StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2920: ----------------------------------------------- Osamu Nagano <onagano(a)redhat.com> changed the Status of [bug 1064644|https://bugzilla.redhat.com/show_bug.cgi?id=1064644] from NEW to ASSIGNED > StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject > -------------------------------------------------------------------------------------------------- > > Key: WFLY-2920 > URL: https://issues.jboss.org/browse/WFLY-2920 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: IIOP > Affects Versions: 8.0.0.Final > Reporter: Osamu Nagano > Assignee: Stefan Guilhen > Attachments: td.dump > > > Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}. Here is the stack trace from the attached thread dump. > {code} > "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000] > java.lang.Thread.State: RUNNABLE > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116) > at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177) > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116) > at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62) > at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > ... > at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177) > at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105) > at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53) > at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104) > at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50) > Locked ownable synchronizers: > - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker) > {code} > The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost. The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment. > The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}. It is reproducible by manually controlling a thread context switch using a debugger. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3051) JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode

by Rituraj Sinha (JIRA)

Rituraj Sinha created WFLY-3051: ----------------------------------- Summary: JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode Key: WFLY-3051 URL: https://issues.jboss.org/browse/WFLY-3051 Project: WildFly Issue Type: Task Security Level: Public (Everyone can see) Components: JMX, Remoting Reporter: Rituraj Sinha Assignee: Kabir Khan Priority: Critical i have gone through the below link for JMX subsystem for wildfly 8 as https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ... can someone please give us the steps to configure JMX through jconsole...? changes done on the domain.xml are the same as stated above <subsystem xmlns="urn:jboss:domain:jmx:1.3"> <expose-resolved-model/> <expose-expression-model/> <remoting-connector use-management-endpoint="false"/> </subsystem> <subsystem xmlns="urn:jboss:domain:jmx:1.3"> <expose-resolved-model/> <expose-expression-model/> <remoting-connector use-management-endpoint="false"/> </subsystem> as per the jboss-as-jmx_1_3.xsd its like <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" > <xs:annotation> <xs:documentation> If true then this connector will use the management endpoint, otherwise it will use the remoting subsystem endpoint. </xs:documentation> </xs:annotation> </xs:attribute> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it.... below is what i am able to connect to service:jmx:http-remoting-jmx://remote_hostA:9990 -- Unknown macro: {host A is where my domain_controller is running} how can i access the server-instances running on domain_controller Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each} i am trying to connect with the below url as service:jmx:http-remoting-jmx://lremote_hostA:8180 let me know if something is missing from my side... Thanks -- 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, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2014