March 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2364) [DMN Editor] Cannot embed a Decision Table in a Function

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2364?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2364: ----------------------------------- Sprint: 2018 Week 09-10 > [DMN Editor] Cannot embed a Decision Table in a Function > -------------------------------------------------------- > > Key: DROOLS-2364 > URL: https://issues.jboss.org/browse/DROOLS-2364 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > > An error ("Uncaught error on client side: Condition 'headerMetaData has at least one entry' is invalid!") is thrown when trying to nest a Decision Table in a Function. This is because a {{FunctionDefinition}} does not implement {{HasName}} and therefore it is not possible to construct an {{OutputClause}} column. > Need to add a different type of non-editable {{HeaderMetaData}} in these scenarios. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1523) Update the JAPICMP settings so that we only detect changes that break API compatibility

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-1523?page=com.atlassian.jira.plugin.s... ] Farah Juma reassigned ELY-1523: ------------------------------- Assignee: Jan Kalina > Update the JAPICMP settings so that we only detect changes that break API compatibility > --------------------------------------------------------------------------------------- > > Key: ELY-1523 > URL: https://issues.jboss.org/browse/ELY-1523 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Farah Juma > Assignee: Jan Kalina > > Currently, the JAPICMP settings will result in a build failure if new public API has been added. As we will be tagging .Final releases more regularly, we need to be able to allow new public API into a patch release so we should only be detecting changes that break API compatibility not changes that add new public API. > As an example, try building the 1.2.1.Final tag (https://github.com/wildfly-security/wildfly-elytron/tree/1.2.1.Final). The build will fail due to new public API unless the -DskipCompatibility flag is passed in. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1523) Update the JAPICMP settings so that we only detect changes that break API compatibility

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-1523?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1523: ---------------------------- Description: Currently, the JAPICMP settings will result in a build failure if new public API has been added. As we will be tagging .Final releases more regularly, we need to be able to allow new public API into a patch release so we should only be detecting changes that break API compatibility not changes that add new public API. As an example, try building the 1.2.1.Final tag (https://github.com/wildfly-security/wildfly-elytron/tree/1.2.1.Final). The build will fail due to new public API unless the -DskipCompatibility flag is passed in. was:Currently, the JAPICMP settings will result in a build failure if new public API has been added. As we will be tagging .Final releases more regularly, we need to be able to allow new public API into a patch release so we should only be detecting changes that break API compatibility not changes that add new public API. > Update the JAPICMP settings so that we only detect changes that break API compatibility > --------------------------------------------------------------------------------------- > > Key: ELY-1523 > URL: https://issues.jboss.org/browse/ELY-1523 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Farah Juma > > Currently, the JAPICMP settings will result in a build failure if new public API has been added. As we will be tagging .Final releases more regularly, we need to be able to allow new public API into a patch release so we should only be detecting changes that break API compatibility not changes that add new public API. > As an example, try building the 1.2.1.Final tag (https://github.com/wildfly-security/wildfly-elytron/tree/1.2.1.Final). The build will fail due to new public API unless the -DskipCompatibility flag is passed in. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1523) Update the JAPICMP settings so that we only detect changes that break API compatibility

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-1523?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1523: ---------------------------- Comment: was deleted (was: A comment with security level 'Red Hat Employee' was removed.) > Update the JAPICMP settings so that we only detect changes that break API compatibility > --------------------------------------------------------------------------------------- > > Key: ELY-1523 > URL: https://issues.jboss.org/browse/ELY-1523 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Farah Juma > > Currently, the JAPICMP settings will result in a build failure if new public API has been added. As we will be tagging .Final releases more regularly, we need to be able to allow new public API into a patch release so we should only be detecting changes that break API compatibility not changes that add new public API. > As an example, try building the 1.2.1.Final tag (https://github.com/wildfly-security/wildfly-elytron/tree/1.2.1.Final). The build will fail due to new public API unless the -DskipCompatibility flag is passed in. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9955) Compatibility problem: allow a timeout value of "0" to be set

by David Lloyd (JIRA)

David Lloyd created WFLY-9955: --------------------------------- Summary: Compatibility problem: allow a timeout value of "0" to be set Key: WFLY-9955 URL: https://issues.jboss.org/browse/WFLY-9955 Project: WildFly Issue Type: Bug Components: Transactions Reporter: David Lloyd Assignee: Tom Jenkinson Previously we allowed a transaction timeout value of "0" to be set in the transaction subsystem, meaning "no transaction timeout". After the WF 11 changes, we've stopped allowing that value to be set. This behavior should be restored, with "0" translating into some "very large" value. The transaction team has indicated that using {{Integer.MAX_VALUE}} has historically exhibited problems, so a different, smaller-but-still-large value should be used in this case. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1480) Support timezones in date and type variables

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1480?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-1480: ---------------------------------- Issue Type: Bug (was: Enhancement) > Support timezones in date and type variables > -------------------------------------------- > > Key: DROOLS-1480 > URL: https://issues.jboss.org/browse/DROOLS-1480 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.0.0.Beta7 > Reporter: Tibor Zimányi > Assignee: Fedor Gavrilov > Labels: reported-by-qe > > Currently we don't support timezones in date and time variables. This should be implemented, when we are sure about the exact format of timezones. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9954) Too many services created for EJBs

by David Lloyd (JIRA)

David Lloyd created WFLY-9954: --------------------------------- Summary: Too many services created for EJBs Key: WFLY-9954 URL: https://issues.jboss.org/browse/WFLY-9954 Project: WildFly Issue Type: Bug Components: EJB Reporter: David Lloyd Priority: Critical If a deployment contains more than 2730 EJBs, the deployment's INSTALL phase will get a stack trace like this: {noformat} 2018-03-25 08:22:34,115 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."example.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."example.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "example.jar" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.IllegalArgumentException: Too many dependencies specified (max is 16383) .......... (*1) at org.jboss.msc.service.ServiceBuilderImpl.doAddDependency(ServiceBuilderImpl.java:216) at org.jboss.msc.service.ServiceBuilderImpl.addDependenciesNoCheck(ServiceBuilderImpl.java:158) at org.jboss.msc.service.ServiceBuilderImpl.addDependencies(ServiceBuilderImpl.java:152) at org.jboss.msc.service.ServiceBuilderImpl.addDependencies(ServiceBuilderImpl.java:142) at org.jboss.as.naming.deployment.JndiNamingDependencyProcessor.deploy(JndiNamingDependencyProcessor.java:59) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) ... 5 more {noformat} The reason is that the INSTALL phase has six additional dependencies per EJB: * service jboss.naming.context.java.comp.example.example.<class-name>.InAppClientContainer * service jboss.naming.context.java.comp.example.example.<class-name>.InstanceName * service jboss.deployment.unit."example.jar".component.<class-name>.JndiBindingsService * service jboss.naming.context.java.comp.example.example.<class-name>.UserTransaction * service jboss.naming.context.java.comp.example.example.<class-name>.TransactionSynchronizationRegistry * service jboss.naming.context.java.comp.example.example.<class-name>.BeanManager We probably should not be creating N dependencies per deployment object since all the services of a given kind are always started together. They could be grouped at a deployment level instead. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1480) Support timezones in date and type variables

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1480?page=com.atlassian.jira.plugi... ] Edson Tirelli updated DROOLS-1480: ---------------------------------- Priority: Major (was: Minor) > Support timezones in date and type variables > -------------------------------------------- > > Key: DROOLS-1480 > URL: https://issues.jboss.org/browse/DROOLS-1480 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Affects Versions: 7.0.0.Beta7 > Reporter: Tibor Zimányi > Assignee: Edson Tirelli > Labels: reported-by-qe > > Currently we don't support timezones in date and time variables. This should be implemented, when we are sure about the exact format of timezones. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1480) Support timezones in date and type variables

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1480?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-1480: ------------------------------------- Assignee: Fedor Gavrilov (was: Edson Tirelli) > Support timezones in date and type variables > -------------------------------------------- > > Key: DROOLS-1480 > URL: https://issues.jboss.org/browse/DROOLS-1480 > Project: Drools > Issue Type: Enhancement > Components: dmn engine > Affects Versions: 7.0.0.Beta7 > Reporter: Tibor Zimányi > Assignee: Fedor Gavrilov > Labels: reported-by-qe > > Currently we don't support timezones in date and time variables. This should be implemented, when we are sure about the exact format of timezones. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9949) Wildfly 12 : jboss-cli.sh in infinite loop

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFLY-9949?page=com.atlassian.jira.plugin.... ] Jean-Francois Denise commented on WFLY-9949: -------------------------------------------- Looking at: https://github.com/lxc/lxd/issues/1724 it seems that tty returns "not a tty" but doesn't fail. So we take "not a tty" as the tty value. > Wildfly 12 : jboss-cli.sh in infinite loop > ------------------------------------------- > > Key: WFLY-9949 > URL: https://issues.jboss.org/browse/WFLY-9949 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: 12.0.0.Final > Environment: ubuntu 16.06 lxd container > java version "1.8.0_161" oracle > v12 migrated from v11 > Reporter: Gaétan QUENTIN > Assignee: Jean-Francois Denise > Labels: regression > Attachments: jboss-cli-logging.properties, jboss-cli.25300, term.txt > > > i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to with wildfly 12: > > wildfly@java2:/opt/Wildfly$ ls -la > drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration > drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays > drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts > drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final > drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final > lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final > > > my wildfly management console is on 172.20.12.192. > v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip. > > > with wildfly-current link on -> wildfly-11.0.0.Final: > > this works perfectly: > (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990) > > > with wildfly-current -> wildfly-12.0.0.Final: > this go in infinite loop until crash : > (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990) > > output: > > '[standalone@172.20.12.192:9990' is not a valid operation name. > [standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name. > ''[standalone@172.20.12.192:9990'' is not a valid operation name. > [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name. > '[standalone@172.20.12.192:9990' is not a valid operation name. > [standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name. > ''''[standalone@172.20.12.192:9990'''' is not a valid operation name. > [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name. > '[standalone@172.20.12.192:9990' is not a valid operation name. > [standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name. > ''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name. > attached is a strace capture file (one of thousands) of jboss-cli . -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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 2018