[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
[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
[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
[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
[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