March 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-391) Support class literals with complex constraints and custom evaluators

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-391?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-391: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1063795|https://bugzilla.redhat.com/show_bug.cgi?id=1063795] from ON_QA to VERIFIED > Support class literals with complex constraints and custom evaluators > --------------------------------------------------------------------- > > Key: DROOLS-391 > URL: https://issues.jboss.org/browse/DROOLS-391 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.5.1.Final, 6.0.0.Final > Reporter: Davide Sottara > Assignee: Mario Fusco > Fix For: 6.1.0.Beta1 > > > The following is supported, when A is a class name: > {code} Pattern( this op A ) {code} > But the following fails with a CCE > {code} Pattern( this op A || this op B ) {code} > when it tries to resolve A as a field of the class Pattern -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-444) NOT conditional element is broken when used with subnetworks

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-444?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-444: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1072462|https://bugzilla.redhat.com/show_bug.cgi?id=1072462] from ON_QA to VERIFIED > NOT conditional element is broken when used with subnetworks > ------------------------------------------------------------ > > Key: DROOLS-444 > URL: https://issues.jboss.org/browse/DROOLS-444 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Final, 6.0.1.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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3108) Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-3108?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-3108: ----------------------------------- Bugzilla Update: (was: Perform) > Can't promote --backup slave HC to master and reload without moving domain.cached-remote.xml > -------------------------------------------------------------------------------------------- > > Key: WFLY-3108 > URL: https://issues.jboss.org/browse/WFLY-3108 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.1.Final > > > The prescribed mechanism for converting a slave HC to master is to: > 1) Start the slave with --backup so a local copy of the domain config is maintained (in file domain.cached-remote.xml). > 2) Stop the existing master. > 3) Use the cli to connect to the slave and > /host=<slavename>:write-local-domain-controller > 4) Then, in the CLI > reload --host=<slavename> > Problem is this fails because the HC expects to have a domain config file "domain.xml". > 2014-03-13 09:54:04,829 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010932: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:514) [wildfly-host-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:256) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] > Caused by: java.io.FileNotFoundException: /Users/bstansberry/tmp/WF801/slave/domain/configuration/domain.xml (No such file or directory) > at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_45] > at java.io.FileInputStream.<init>(FileInputStream.java:146) [rt.jar:1.7.0_45] > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:100) [wildfly-controller-8.0.1.Final-SNAPSHOT.jar:8.0.1.Final-SNAPSHOT] > ... 3 more > Or, MUCH WORSE, there happens to be a random domain.xml in the filesystem, which has content that is out of sync with the correct domain config. This domain.xml config will be used. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (JBAS-9560) implemtentation of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup

by Tomas Lamr (JIRA)

[ https://issues.jboss.org/browse/JBAS-9560?page=com.atlassian.jira.plugin.... ] Tomas Lamr updated JBAS-9560: ----------------------------- Summary: implemtentation of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup (was: child of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup) JBEAP-52 > implemtentation of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup > --------------------------------------------------------------------------------------------------- > > Key: JBAS-9560 > URL: https://issues.jboss.org/browse/JBAS-9560 > Project: Application Server 3 4 5 and 6 > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remoting > Affects Versions: 6.1.0 > Environment: debian testing > Reporter: Tomas Lamr > > Reproducible also on jboss eap 6.2 i.e. AS 7.3. > We have an legacy j2ee app that runs on many application servers. We are trying to port it to AS 7.x, but found one issue. > We use java rmi. Our remote interface implementation (ImplClass) extends java.rmi.server.UnicastRemoteObject. We have a singleton instance of this class in our app that is initialized at the start of the application and then bound into the jndi tree. > For this, we use a context created with org.jboss.as.naming.InitialContextFactory as java.naming.factory.initial > We bind to "java:jboss/exported/" prefix and it works for us for all the other simple values but not for our ImplClass. > When doing lookup on the server, the jndi lookup returns correctly an instance that was created on the server pointing to local connection, but when doing lookup on client with this context > {code} > org.jboss.naming.remote.client.InitialContextFactory > remote://localhost:port/ > {code} > we retrieve the same instance as on the server that point to local connection. Hence it seems, that our object is always copied and sent as a value to the client instead of sending the remote proxy which can be used on the client. > The same code works on jboss AS 5.1 (when using jnp) and also on netweaver, websphere and weblogic when using their context implementations. > It would be great if this could be also fixed in jboss as 7.x. > Known workaround: Use a java.rmi.registry.Registry on the server for registering proxy instead of jndi. > According to this site (and possibly some spec) > http://www.javaworld.com/article/2076234/soa/get-smart-with-proxies-and-r... > an object should be passed by value if and only if it is implementing Serializable interface, but the current implementation in jboss as 7.x does not respect this and always passes objects by value. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (JBAS-9560) child of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup

by Tomas Lamr (JIRA)

[ https://issues.jboss.org/browse/JBAS-9560?page=com.atlassian.jira.plugin.... ] Tomas Lamr updated JBAS-9560: ----------------------------- Issue created for the wrong project, please close. > child of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup > ----------------------------------------------------------------------------------------- > > Key: JBAS-9560 > URL: https://issues.jboss.org/browse/JBAS-9560 > Project: Application Server 3 4 5 and 6 > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remoting > Affects Versions: 6.1.0 > Environment: debian testing > Reporter: Tomas Lamr > > Reproducible also on jboss eap 6.2 i.e. AS 7.3. > We have an legacy j2ee app that runs on many application servers. We are trying to port it to AS 7.x, but found one issue. > We use java rmi. Our remote interface implementation (ImplClass) extends java.rmi.server.UnicastRemoteObject. We have a singleton instance of this class in our app that is initialized at the start of the application and then bound into the jndi tree. > For this, we use a context created with org.jboss.as.naming.InitialContextFactory as java.naming.factory.initial > We bind to "java:jboss/exported/" prefix and it works for us for all the other simple values but not for our ImplClass. > When doing lookup on the server, the jndi lookup returns correctly an instance that was created on the server pointing to local connection, but when doing lookup on client with this context > {code} > org.jboss.naming.remote.client.InitialContextFactory > remote://localhost:port/ > {code} > we retrieve the same instance as on the server that point to local connection. Hence it seems, that our object is always copied and sent as a value to the client instead of sending the remote proxy which can be used on the client. > The same code works on jboss AS 5.1 (when using jnp) and also on netweaver, websphere and weblogic when using their context implementations. > It would be great if this could be also fixed in jboss as 7.x. > Known workaround: Use a java.rmi.registry.Registry on the server for registering proxy instead of jndi. > According to this site (and possibly some spec) > http://www.javaworld.com/article/2076234/soa/get-smart-with-proxies-and-r... > an object should be passed by value if and only if it is implementing Serializable interface, but the current implementation in jboss as 7.x does not respect this and always passes objects by value. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (JBAS-9560) child of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup

by Tomas Lamr (JIRA)

Tomas Lamr created JBAS-9560: -------------------------------- Summary: child of java.rmi.server.UnicastRemoteObject always sent as value when remote jndi lookup Key: JBAS-9560 URL: https://issues.jboss.org/browse/JBAS-9560 Project: Application Server 3 4 5 and 6 Issue Type: Bug Security Level: Public (Everyone can see) Components: Remoting Affects Versions: 6.1.0 Environment: debian testing Reporter: Tomas Lamr Reproducible also on jboss eap 6.2 i.e. AS 7.3. We have an legacy j2ee app that runs on many application servers. We are trying to port it to AS 7.x, but found one issue. We use java rmi. Our remote interface implementation (ImplClass) extends java.rmi.server.UnicastRemoteObject. We have a singleton instance of this class in our app that is initialized at the start of the application and then bound into the jndi tree. For this, we use a context created with org.jboss.as.naming.InitialContextFactory as java.naming.factory.initial We bind to "java:jboss/exported/" prefix and it works for us for all the other simple values but not for our ImplClass. When doing lookup on the server, the jndi lookup returns correctly an instance that was created on the server pointing to local connection, but when doing lookup on client with this context {code} org.jboss.naming.remote.client.InitialContextFactory remote://localhost:port/ {code} we retrieve the same instance as on the server that point to local connection. Hence it seems, that our object is always copied and sent as a value to the client instead of sending the remote proxy which can be used on the client. The same code works on jboss AS 5.1 (when using jnp) and also on netweaver, websphere and weblogic when using their context implementations. It would be great if this could be also fixed in jboss as 7.x. Known workaround: Use a java.rmi.registry.Registry on the server for registering proxy instead of jndi. According to this site (and possibly some spec) http://www.javaworld.com/article/2076234/soa/get-smart-with-proxies-and-r... an object should be passed by value if and only if it is implementing Serializable interface, but the current implementation in jboss as 7.x does not respect this and always passes objects by value. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-426) Globals can't be used with temporal operators

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-426?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-426: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1064224|https://bugzilla.redhat.com/show_bug.cgi?id=1064224] from ON_QA to VERIFIED > Globals can't be used with temporal operators > --------------------------------------------- > > Key: DROOLS-426 > URL: https://issues.jboss.org/browse/DROOLS-426 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Davide Sottara > Assignee: Mario Fusco > Priority: Critical > Fix For: 6.1.0.Beta1 > > > Assuming: > global Date now; > The pattern "Foo( this before now )" will generate various errors. > The reason is that the Global[X]Extractors (X = {"","Date","Number"} > are erroneously declared as self-referential extractors. > If Foo is not an @event, a CCE will arise since the operators will use > "this" rather than the global. Otherwise, the result will be 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, 3 months

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: ------------------------------------------------ Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1063809|https://bugzilla.redhat.com/show_bug.cgi?id=1063809] from ON_QA to VERIFIED > 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3124) JXM PluggableMBeanServerImpl assumes RealmUser principal

by Vojtech Juranek (JIRA)

Vojtech Juranek created WFLY-3124: ------------------------------------- Summary: JXM PluggableMBeanServerImpl assumes RealmUser principal Key: WFLY-3124 URL: https://issues.jboss.org/browse/WFLY-3124 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: 8.0.0.Final Reporter: Vojtech Juranek Assignee: Kabir Khan JXM {{PluggableMBeanServerImpl$LogAction}} assumes that {{RealmUser}} principal is present when Subject is not null. This condition is not always met and results into following exception: {noformat} Caused by: java.util.NoSuchElementException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:929) at java.util.HashMap$KeyIterator.next(HashMap.java:960) at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.getCallerUserId(PluggableMBeanServerImpl.java:1250) at org.jboss.as.jmx.PluggableMBeanServerImpl$LogAction.doLog(PluggableMBeanServerImpl.java:1233) at org.jboss.as.jmx.PluggableMBeanServerImpl.log(PluggableMBeanServerImpl.java:1158) at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.log(MBeanServerAuditLogRecordFormatter.java:331) at org.jboss.as.jmx.MBeanServerAuditLogRecordFormatter.queryNames(MBeanServerAuditLogRecordFormatter.java:170) at org.jboss.as.jmx.PluggableMBeanServerImpl.queryNames(PluggableMBeanServerImpl.java:871) at org.infinispan.jmx.JmxUtil.findJmxDomain(JmxUtil.java:127) {noformat} -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (JBEE-152) Release JSP 2.3 APIs

by Shelly McGowan (JIRA)

Shelly McGowan created JBEE-152: ----------------------------------- Summary: Release JSP 2.3 APIs Key: JBEE-152 URL: https://issues.jboss.org/browse/JBEE-152 Project: JBoss JavaEE Spec APIs Issue Type: Bug Components: jboss-jsp-api Reporter: Shelly McGowan Assignee: Shelly McGowan JSP update needed to include bug fix: https://github.com/jboss/jboss-jsp-api_spec/commit/219be2052b0487624f209f... -- 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, 3 months

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