[JBoss JIRA] (DROOLS-2880) Show all top level custom Data Types in the dialog, instead of only the selected one
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2880?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2880:
--------------------------------
Description:
Show all top level custom Data Types in the dialog, instead of only the selected one. Even when the user does not have any ItemDefinition, the dialog must lunch.
h3. Acceptance test
- No definitions present
- Invalid definition present
- Unsupported definition present
- More than 20 definitions present
was:Show all top level custom Data Types in the dialog, instead of only the selected one. Even when the user does not have any ItemDefinition, the dialog must lunch.
> Show all top level custom Data Types in the dialog, instead of only the selected one
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-2880
> URL: https://issues.jboss.org/browse/DROOLS-2880
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Guilherme Carreiro
> Assignee: Guilherme Carreiro
> Labels: drools-tools
>
> Show all top level custom Data Types in the dialog, instead of only the selected one. Even when the user does not have any ItemDefinition, the dialog must lunch.
> h3. Acceptance test
> - No definitions present
> - Invalid definition present
> - Unsupported definition present
> - More than 20 definitions present
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-10829) Exclude ironjacamar-spec-api from the transitive depenencies
by Yeray Borges (JIRA)
[ https://issues.jboss.org/browse/WFLY-10829?page=com.atlassian.jira.plugin... ]
Yeray Borges commented on WFLY-10829:
-------------------------------------
Sadly, it looks like I did not see this issue when I was working on WFLY-10918. {{ironjacamar-spec-api}} was excluded as a transitive dependency from {{ironjacamar-common-impl}} and {{ironjacamar-core-api}} but not from {{ironjacamar-core-impl}}
Even if the final solution to address this issue is to move the dependency scope in Iron Jamacar project to provider, at least for consistency, we should exclude {{ironjacamar-core-api}} from {{ironjacamar-core-impl}} in Wildfly.
[~maeste][~gaol] Sorry for the mess, but if you agree with the above, maybe you can use this issue to add the pending exclusion in wildfly as well.
> Exclude ironjacamar-spec-api from the transitive depenencies
> ------------------------------------------------------------
>
> Key: WFLY-10829
> URL: https://issues.jboss.org/browse/WFLY-10829
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Kabir Khan
> Assignee: Stefano Maestri
>
> Although not part of the server runtime, the ironjacamar-spec-api is included as a transitive dependency. This fixes it:
> {code}
> --- pom.xml
> +++ pom.xml
> @@ -4314,6 +4326,10 @@
> <version>\${version.org.jboss.ironjacamar}</version>
> <exclusions>
> <exclusion>
> + <artifactId>ironjacamar-spec-api</artifactId>
> + <groupId>org.jboss.ironjacamar</groupId>
> + </exclusion>
> + <exclusion>
> <artifactId>jbossxb</artifactId>
> <groupId>org.jboss</groupId>
> </exclusion>
> @@ -4346,6 +4362,10 @@
> <version>\${version.org.jboss.ironjacamar}</version>
> <exclusions>
> <exclusion>
> + <groupId>org.jboss.ironjacamar</groupId>
> + <artifactId>ironjacamar-spec-api</artifactId>
> + </exclusion>
> + <exclusion>
> <artifactId>jboss-integration</artifactId>
> <groupId>org.jboss.integration</groupId>
> </exclusion>
> @@ -4376,6 +4396,10 @@
> <version>\${version.org.jboss.ironjacamar}</version>
> <exclusions>
> <exclusion>
> + <groupId>org.jboss.ironjacamar</groupId>
> + <artifactId>ironjacamar-spec-api</artifactId>
> + </exclusion>
> + <exclusion>
> <artifactId>jboss-common-core</artifactId>
> <groupId>org.jboss</groupId>
> </exclusion>
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-10879) Deployment is not failing as expected and according to the specification if a @Singleton @Startup @PostConstruct initialization failed
by Bartosz Spyrko-Śmietanko (JIRA)
[ https://issues.jboss.org/browse/WFLY-10879?page=com.atlassian.jira.plugin... ]
Bartosz Spyrko-Śmietanko updated WFLY-10879:
--------------------------------------------
Component/s: EJB
> Deployment is not failing as expected and according to the specification if a @Singleton @Startup @PostConstruct initialization failed
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10879
> URL: https://issues.jboss.org/browse/WFLY-10879
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
> Attachments: server.log
>
>
> According to the spec (see below excerpt of ejb3.2 specification) the application should not avaialble if a Singleton initialization has failed.
> The current behaviour with two ejb.jar's in one ear, or other combinations is
> that the failure is logged, the deployment seems removed (there is a APP.ear.failed marker file) but another EJB of a second jar inside the ear is accesible, also web applications war deployemts are started.
> from the Spec 3.2
> 4.8.1 Singleton Session Bean Initialization
> By default, the container is responsible for deciding when to initialize a singleton session bean instance.
> However, the Bean Provider can optionally configure the singleton session bean for eager initialization.
> If the Startup annotation appears on the singleton session bean class or if the singleton session bean
> has been designated via the deployment descriptor as requiring eager initialization, the container must
> initialize the singleton session bean instance during the application startup sequence.
> ***** The container must initialize all such startup-time singleton session beans before any external client requests (that is,
> client requests originating outside of the application) are delivered to any enterprise bean components in
> the application. ******
> 4.8.4 Singleton SB error handling
> Errors occurring during singleton session bean initialization are considered fatal and must result in the
> discarding of the singleton session bean instance. ...
> If a singleton session bean fails to initialize, attempted invocations on the singleton session bean result in the
> javax.ejb.NoSuchEJBException exception as defined by Section 3.4.3 and Section 3.4.4 .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-10951) JDK11 - SSLException caused by SocketException: Broken pipe
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10951?page=com.atlassian.jira.plugin... ]
Jan Kalina updated WFLY-10951:
------------------------------
Summary: JDK11 - SSLException caused by SocketException: Broken pipe (was: JDK11 SSLException:)
> JDK11 - SSLException caused by SocketException: Broken pipe
> -----------------------------------------------------------
>
> Key: WFLY-10951
> URL: https://issues.jboss.org/browse/WFLY-10951
> Project: WildFly
> Issue Type: Sub-task
> Components: Test Suite
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following exception occure instead of {{SSLHandshakeException | SocketException}}:
> {code}
> javax.net.ssl.SSLException: readHandshakeRecord
> Caused by: java.net.SocketException: Broken pipe (Write failed)
> {code}
> To reproduce:
> {code}
> cd testsuite/integration/elytron
> JAVA_HOME=/opt/jdk-11/ PATH=$JAVA_HOME/bin:$PATH mvn test -Dtest=UndertowTwoWaySslNeedClientAuthTestCase
> {code}
> {code}
> cd testsuite/integration/manualmode
> JAVA_HOME=/opt/jdk-11+28/ PATH=$JAVA_HOME/bin:$PATH mvn test -Dtest=HTTPSWebConnectorTestCase
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (WFLY-10951) JDK11 SSLException:
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-10951?page=com.atlassian.jira.plugin... ]
Jan Kalina updated WFLY-10951:
------------------------------
Summary: JDK11 SSLException: (was: JDK11 elytron UndertowTwoWaySslNeedClientAuthTestCase failure)
> JDK11 SSLException:
> -------------------
>
> Key: WFLY-10951
> URL: https://issues.jboss.org/browse/WFLY-10951
> Project: WildFly
> Issue Type: Sub-task
> Components: Test Suite
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> Following exception occure instead of {{SSLHandshakeException | SocketException}}:
> {code}
> javax.net.ssl.SSLException: readHandshakeRecord
> Caused by: java.net.SocketException: Broken pipe (Write failed)
> {code}
> To reproduce:
> {code}
> cd testsuite/integration/elytron
> JAVA_HOME=/opt/jdk-11/ PATH=$JAVA_HOME/bin:$PATH mvn test -Dtest=UndertowTwoWaySslNeedClientAuthTestCase
> {code}
> {code}
> cd testsuite/integration/manualmode
> JAVA_HOME=/opt/jdk-11+28/ PATH=$JAVA_HOME/bin:$PATH mvn test -Dtest=HTTPSWebConnectorTestCase
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month