August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1714) Accumulate compile issue with java dialect

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1714?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1714: -------------------------------- Sprint: 2017 Week 34-35 > Accumulate compile issue with java dialect > ------------------------------------------ > > Key: DROOLS-1714 > URL: https://issues.jboss.org/browse/DROOLS-1714 > Project: Drools > Issue Type: Bug > Affects Versions: 7.2.0.Final > Reporter: Justin Goldsmith > Assignee: Mario Fusco > Fix For: 7.3.0.Final > > > when using java dialect in a accumulate, if there is a binding in the accumulate to a type that is not imported, you get a class cast error instead of the normal unable to resolve > "object.java.lang.ClassCastException: org.drools.compiler.rule.builder.dialect.mvel.MVELAnalysisResult cannot be cast to org.drools.compiler.rule.builder.dialect.java.JavaAnalysisResult" > Please see the following reproducer with three test cases that expect failure. > 2 of the tests have the expected failure, one does not. > https://github.com/jgoldsmith613/drools-accumulate-bug -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1714) Accumulate compile issue with java dialect

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1714?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1714. --------------------------------- Fix Version/s: 7.3.0.Final Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/8df302bbfe3084146f7979e7a7e8da7... > Accumulate compile issue with java dialect > ------------------------------------------ > > Key: DROOLS-1714 > URL: https://issues.jboss.org/browse/DROOLS-1714 > Project: Drools > Issue Type: Bug > Affects Versions: 7.2.0.Final > Reporter: Justin Goldsmith > Assignee: Mario Fusco > Fix For: 7.3.0.Final > > > when using java dialect in a accumulate, if there is a binding in the accumulate to a type that is not imported, you get a class cast error instead of the normal unable to resolve > "object.java.lang.ClassCastException: org.drools.compiler.rule.builder.dialect.mvel.MVELAnalysisResult cannot be cast to org.drools.compiler.rule.builder.dialect.java.JavaAnalysisResult" > Please see the following reproducer with three test cases that expect failure. > 2 of the tests have the expected failure, one does not. > https://github.com/jgoldsmith613/drools-accumulate-bug -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-128) Create the ability to close or destroy a LogContext

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-128?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-128: -------------------------------------- Instead of a close we might just want {{reset()}} or {{clear()}}. Nothing will really be closed, especially on the system log context. > Create the ability to close or destroy a LogContext > --------------------------------------------------- > > Key: LOGMGR-128 > URL: https://issues.jboss.org/browse/LOGMGR-128 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: James Perkins > Assignee: James Perkins > > The {{org.jboss.logmanager.LogContext}} should have the ability to be closed or better put destroyed. Each logger, formatter, error-handler and handler would be removed and closed if required. > This is useful for things like the WildFly embedded CLI server when the embedded log context needs to be destroyed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-128) Create the ability to close or destroy a LogContext

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-128?page=com.atlassian.jira.plugin... ] James Perkins reassigned LOGMGR-128: ------------------------------------ Assignee: James Perkins (was: Ken Wills) > Create the ability to close or destroy a LogContext > --------------------------------------------------- > > Key: LOGMGR-128 > URL: https://issues.jboss.org/browse/LOGMGR-128 > Project: JBoss Log Manager > Issue Type: Feature Request > Reporter: James Perkins > Assignee: James Perkins > > The {{org.jboss.logmanager.LogContext}} should have the ability to be closed or better put destroyed. Each logger, formatter, error-handler and handler would be removed and closed if required. > This is useful for things like the WildFly embedded CLI server when the embedded log context needs to be destroyed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8357) jboss-ejb-iiop_1_0.xsd is invalid

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8357?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-8357: ----------------------------------------------- Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1192591|https://bugzilla.redhat.com/show_bug.cgi?id=1192591] from ON_QA to ASSIGNED > jboss-ejb-iiop_1_0.xsd is invalid > --------------------------------- > > Key: WFLY-8357 > URL: https://issues.jboss.org/browse/WFLY-8357 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Radovan Netuka > Priority: Critical > Labels: downstream_dependency > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9263) Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home

by Nuno Godinho de Matos (JIRA)

Nuno Godinho de Matos created WFLY-9263: ------------------------------------------- Summary: Feature Request - Development tools - eclipse launch configurations should be possible to be inferred from domain home Key: WFLY-9263 URL: https://issues.jboss.org/browse/WFLY-9263 Project: WildFly Issue Type: Bug Components: Scripts Affects Versions: 10.1.0.Final Reporter: Nuno Godinho de Matos Assignee: Tomaz Cerar Priority: Optional Hi, I believe that eclipse development with wildfly is quite cumbersome at the moment of defining a new wildfly domain runtime, in particular in regard to the resutilng "open launch configurations". When we consider what happens with weblogic domains, they normally all have a dedicated bin/ folder. I do the same thing when a create a fresh new wildfly domain, i enrich it with an additional bin/ folder where I pump in scripts to start/stop etc.. the domain. Where in particular, the start script is created with properties like java options that matter to our deployments. Weblogic start plugin uses the startWeblogic.cmd in the bin folder. Naturally, this does not happen on Wildfly because the concept for the bin scripts is different. They are generic and domain independent. But It would in any case be very nice, if it were possible to have some sort of convention that when the eclipse plugin looks at a stand alone domain, it could at least hunt for some sort of configuration file, such as an .eclipse_launch_parameters config, to override the default settings. If such a mechanism would exist, i could enhance my create domain logic to pump into such a configuration file the same setting that is use in my start wildfly scripts.bat.sh. As it stands, every time I create a new runtime I need to open the configuration page. Go to the launch configurations, remove the heap settings. And then go to my startup domain scripts, search for the java opts that I care about, and copy them over. This is quite time wasteful. It would be extremely helpful to be able to dodge point and click configuration, once I tell wildfly where the folder for my stand alone domain is located. Many thanks for taking into consideration this enhancement request for widlfly eclipse plugin. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3207) Update to Elytron 1.1.1.Final

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3207?page=com.atlassian.jira.plugi... ] Jason Greene reassigned WFCORE-3207: ------------------------------------ Assignee: Jason Greene > Update to Elytron 1.1.1.Final > ----------------------------- > > Key: WFCORE-3207 > URL: https://issues.jboss.org/browse/WFCORE-3207 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Jason Greene > Assignee: Jason Greene > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1347) Release WildFly Elytron 1.1.1.Final

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/ELY-1347?page=com.atlassian.jira.plugin.s... ] Peter Skopek resolved ELY-1347. ------------------------------- Resolution: Done > Release WildFly Elytron 1.1.1.Final > ----------------------------------- > > Key: ELY-1347 > URL: https://issues.jboss.org/browse/ELY-1347 > Project: WildFly Elytron > Issue Type: Release > Reporter: Peter Skopek > Assignee: Peter Skopek > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7309) Make the authentication configurable in the testsuite

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7309?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7309: ----------------------------------------------- Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1384542|https://bugzilla.redhat.com/show_bug.cgi?id=1384542] from ON_QA to VERIFIED > Make the authentication configurable in the testsuite > ------------------------------------------------------ > > Key: WFLY-7309 > URL: https://issues.jboss.org/browse/WFLY-7309 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 10.1.0.Final > Reporter: Filippe Spolti > Assignee: Filippe Spolti > Priority: Optional > Fix For: 11.0.0.Alpha1 > > > Actually some tests cases fails when running against a remote eap instance. > In this specific case instances running on Openshift v3. > In order to get those tests working we have to modify some classes to configure the authentication. > Example: > org.jboss.as.test.integration.ee.jmx.property.JMXPropertyEditorsTestCase, had to change this: > {code:java} > private MBeanServerConnection getMBeanServerConnection() throws IOException { > final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort(); > connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address)); > return connector.getMBeanServerConnection(); > } > {code} > To: > {code:java} > private MBeanServerConnection getMBeanServerConnection() throws IOException { > HashMap<String, String[]> propEnv = new HashMap<String, String[]>(); > String[] credentials = { System.getProperty("jboss.management.user",""), System.getProperty("jboss.management.password","") }; > propEnv.put(JMXConnector.CREDENTIALS, credentials); > final String address = managementClient.getMgmtAddress()+":"+managementClient.getMgmtPort(); > connector = JMXConnectorFactory.connect(new JMXServiceURL("service:jmx:http-remoting-jmx://"+address),propEnv); > return connector.getMBeanServerConnection(); > } > {code} > Could these kind of authentication being configurable? > It is important to us because this allows the tests to be executed against the docker images running in openshift. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3207) Update to Elytron 1.1.1.Final

by Jason Greene (JIRA)

Jason Greene created WFCORE-3207: ------------------------------------ Summary: Update to Elytron 1.1.1.Final Key: WFCORE-3207 URL: https://issues.jboss.org/browse/WFCORE-3207 Project: WildFly Core Issue Type: Component Upgrade Reporter: Jason Greene -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 August 2017