February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4392) Make use of TCCL in ARQ ManagedContainer configurable

by Thomas Diesler (JIRA)

Thomas Diesler created WFLY-4392: ------------------------------------ Summary: Make use of TCCL in ARQ ManagedContainer configurable Key: WFLY-4392 URL: https://issues.jboss.org/browse/WFLY-4392 Project: WildFly Issue Type: Feature Request Components: Test Suite Reporter: Thomas Diesler Fix For: 9.0.0.Beta1 In WildFly it is considerred intended behaviour that test code gets called with the TCCL set to the test deployment. IMHO this shadows potential problems when the functionality under test is not called from an ARQ test case (i.e. from an normal javaee endpoint) For Camel integration this behaviour is not acceptable. CrossLink: https://github.com/wildfly-extras/wildfly-camel/issues/340 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4389) Upgrade HAL to 2.6.4.Final

by Harald Pehl (JIRA)

[ https://issues.jboss.org/browse/WFLY-4389?page=com.atlassian.jira.plugin.... ] Harald Pehl updated WFLY-4389: ------------------------------ Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/7199) > Upgrade HAL to 2.6.4.Final > -------------------------- > > Key: WFLY-4389 > URL: https://issues.jboss.org/browse/WFLY-4389 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4391) When testing with WildFly Full, the WSTestCase is randomly unstable

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFLY-4391?page=com.atlassian.jira.plugin.... ] ehsavoie Hugonnet moved WFCORE-550 to WFLY-4391: ------------------------------------------------ Project: WildFly (was: WildFly Core) Key: WFLY-4391 (was: WFCORE-550) Affects Version/s: 9.0.0.Alpha1 (was: 1.0.0.Alpha18) Component/s: Test Suite (was: Test Suite) > When testing with WildFly Full, the WSTestCase is randomly unstable > ------------------------------------------------------------------- > > Key: WFLY-4391 > URL: https://issues.jboss.org/browse/WFLY-4391 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > Sometimes the WSTestCase will fail without any reason. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-569) Clean the DiscoveryOption API

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-569?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet updated WFCORE-569: ------------------------------------- Summary: Clean the DiscoveryOption API (was: Clean the DiscoveryIOption API) > Clean the DiscoveryOption API > ----------------------------- > > Key: WFCORE-569 > URL: https://issues.jboss.org/browse/WFCORE-569 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 1.0.0.Alpha19 > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > DiscoveryOption discover should return a list of connection parameters to a DC instead of only one value set into the DiscoveryOption. > Add a ConnectionParameter class with protocol, host and post and returns a list of those when discovering so that we may have multiple options ofr S3 for example. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-730) Decouple Belief System and Truth Maintenance System

by Davide Sottara (JIRA)

Davide Sottara created DROOLS-730: ------------------------------------- Summary: Decouple Belief System and Truth Maintenance System Key: DROOLS-730 URL: https://issues.jboss.org/browse/DROOLS-730 Project: Drools Issue Type: Feature Request Reporter: Davide Sottara Assignee: Mark Proctor -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4390) restartable=false bach job can be restarted

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-4390?page=com.atlassian.jira.plugin.... ] Cheng Fang commented on WFLY-4390: ---------------------------------- Thanks for reporting the issue and providing the test, looking into it now. > restartable=false bach job can be restarted > ------------------------------------------- > > Key: WFLY-4390 > URL: https://issues.jboss.org/browse/WFLY-4390 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 8.2.0.Final > Reporter: Takashi Nishigaya > Assignee: Cheng Fang > Attachments: batch-restartable.zip > > > The batch job defined with restartable=false must not be restartable, after failed or stopped. > GlassFish 4.1 results in the following: > [2015-02-26T19:56:34.860+0900] [glassfish 4.1] [SEVERE] [] [] [tid: _ThreadID=25 _ThreadName=Thread-9] [timeMillis: 1424948194860] [levelValue: 1000] [[ > javax.batch.operations.JobRestartException: javax.batch.operations.JobRestartException: Job Restartable attribute is false, Job cannot be restarted. > But WildFly tries to execute the stopped or failed job. > Please check the attached test case. > wildfly: > $ mvn clean test -P wildfly-managed (or -P wildly-remote) > glassfish: > $ glassfish4/bin/asadmin start-domain > $ mvn clean test -P glassfish-remote -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4390) restartable=false bach job can be restarted

by Cheng Fang (JIRA)

[ https://issues.jboss.org/browse/WFLY-4390?page=com.atlassian.jira.plugin.... ] Cheng Fang reassigned WFLY-4390: -------------------------------- Assignee: Cheng Fang (was: Jason Greene) > restartable=false bach job can be restarted > ------------------------------------------- > > Key: WFLY-4390 > URL: https://issues.jboss.org/browse/WFLY-4390 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 8.2.0.Final > Reporter: Takashi Nishigaya > Assignee: Cheng Fang > Attachments: batch-restartable.zip > > > The batch job defined with restartable=false must not be restartable, after failed or stopped. > GlassFish 4.1 results in the following: > [2015-02-26T19:56:34.860+0900] [glassfish 4.1] [SEVERE] [] [] [tid: _ThreadID=25 _ThreadName=Thread-9] [timeMillis: 1424948194860] [levelValue: 1000] [[ > javax.batch.operations.JobRestartException: javax.batch.operations.JobRestartException: Job Restartable attribute is false, Job cannot be restarted. > But WildFly tries to execute the stopped or failed job. > Please check the attached test case. > wildfly: > $ mvn clean test -P wildfly-managed (or -P wildly-remote) > glassfish: > $ glassfish4/bin/asadmin start-domain > $ mvn clean test -P glassfish-remote -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-161) Deprecated Reflection in security manager

by Jan Kalina (JIRA)

Jan Kalina created ELY-161: ------------------------------ Summary: Deprecated Reflection in security manager Key: ELY-161 URL: https://issues.jboss.org/browse/ELY-161 Project: WildFly Elytron Issue Type: Task Components: Security Manager Reporter: Jan Kalina Priority: Minor WildFly security manager use deprecated API for getting of caller. Currently only public API to look at the call stack as Class instances, which will not be removed in future, is {{SecurityManager.getClassContext()}}, which is inefficient to use in performance critical parts. Efficient replacement of this API not exist yet, should be added in Java 9: https://bugs.openjdk.java.net/browse/JDK-8043814 When mentioned enhancement proposial will be implemented, it shoudl replace current {{SecurityManager.getClassContext()}} fallback. But this new API only replace current fallback for Java 9 - deprecated API must stay for Java 8. This issue is related to following build warning: (mentioned for search) {code} WildFlySecurityManager.java:[117,32] getCallerClass(int) in sun.reflect.Reflection has been deprecated {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-729) Android Support

by Mark Kedzierski (JIRA)

[ https://issues.jboss.org/browse/DROOLS-729?page=com.atlassian.jira.plugin... ] Mark Kedzierski updated DROOLS-729: ----------------------------------- Affects Version/s: 6.0.1.Final Description: I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect. code: http://www.github.com/kedzie/drools-android http://www.github.com/kedzie/drools-android-sample Features: -Dex classloaders for all generated classes -Roboguice integration for injecting knowledge bases from precompiled packages -Maven plugin which pre-compiles rule packages Issues: -Unit tests don't work because it always uses dex classloader, which doesn't work on a desktop system -Haven't tested drools-compiler on android platform I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome. was: I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect. code: http://www.github.com/kedzie/drools-android http://www.github.com/kedzie/drools-android-sample Issues: -Unit tests don't work because it always uses dex classloader, which doesn't work on a desktop system -Haven't tested drools-compiler on android platform I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome. > Android Support > --------------- > > Key: DROOLS-729 > URL: https://issues.jboss.org/browse/DROOLS-729 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 6.0.1.Final > Environment: Android > Reporter: Mark Kedzierski > Assignee: Mario Fusco > Priority: Optional > Labels: Android > > I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect. > code: > http://www.github.com/kedzie/drools-android > http://www.github.com/kedzie/drools-android-sample > Features: > -Dex classloaders for all generated classes > -Roboguice integration for injecting knowledge bases from precompiled packages > -Maven plugin which pre-compiles rule packages > Issues: > -Unit tests don't work because it always uses dex classloader, which doesn't work on a desktop system > -Haven't tested drools-compiler on android platform > I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-729) Android Support

by Mark Kedzierski (JIRA)

Mark Kedzierski created DROOLS-729: -------------------------------------- Summary: Android Support Key: DROOLS-729 URL: https://issues.jboss.org/browse/DROOLS-729 Project: Drools Issue Type: Enhancement Components: core engine Environment: Android Reporter: Mark Kedzierski Assignee: Mario Fusco Priority: Optional I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect. code: http://www.github.com/kedzie/drools-android http://www.github.com/kedzie/drools-android-sample Issues: -Unit tests don't work because it always uses dex classloader, which doesn't work on a desktop system -Haven't tested drools-compiler on android platform I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 1 month

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 February 2015