[JBoss JIRA] (WFLY-5550) Formalize web session clustering modules into a proper subsystem
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-5550?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-5550 at 10/11/18 10:25 AM:
---------------------------------------------------------------
[~tommaso-borgato] Re: jboss-web.xml options:
The link you pasted is documentation from a very old JBoss AS version, i.e. 4.2.2.
* replication-trigger has dropped from version 8.0 of the jboss-web.xml schema and has been ignored since EAP 7.0, following the redesign/reimplementation of the distributed session manager
* FIELD granularity was dropped since EAP5.
* replication-field-batch-mode is specific to FIELD granularity, and was has also dropped in EAP5.
Re: missing options from jboss-web.xml
I do not intend to add any new options to jboss-web.xml. In fact, the entire <replication-config/> is being dropped from the jboss-web.xml schema. Configuration of the distributed session manager will no longer be done via this deployment descriptor, unless a legacy application is deployed (i.e. containing an old version of jboss-web.xml).
was (Author: pferraro):
[~tommaso-borgato] Re: jboss-web.xml options:
The link you pasted is documentation from a very old JBoss AS 4.2.2.
* replication-trigger has dropped from version 8.0 of the jboss-web.xml schema and has been ignored since EAP 7.0, following the redesign/reimplementation of the distributed session manager
* FIELD granularity was dropped since EAP5.
* replication-field-batch-mode is specific to FIELD granularity, and was has also dropped in EAP5.
Re: missing options from jboss-web.xml
I do not intend to add any new options to jboss-web.xml. In fact, the entire <replication-config/> is being dropped from the jboss-web.xml schema. Configuration of the distributed session manager will no longer be done via this deployment descriptor, unless a legacy application is deployed (i.e. containing an old version of jboss-web.xml).
> Formalize web session clustering modules into a proper subsystem
> ----------------------------------------------------------------
>
> Key: WFLY-5550
> URL: https://issues.jboss.org/browse/WFLY-5550
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.CR3
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> Currently, the coupling between the undertow subsystem and the modules required for distributed web session manager and single sign-on manager support is very loose.
> Consequently, misconfiguration (e.g. a missing "web" cache-container) can prevent deployment from succeeding without an adequate explanation.
> The subsystem would define the requisite cache-container, exposed as a capability.
> This subsystem would exposes a number of profiles, containing the configuration traditionally specified in jboss-web.xml, as well as the cache configuration to use (specified by cache-container + cache name). jboss-web.xml would only need to reference a profile by name, or, if unspecified, use the default profile.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11084) inter-app quickstart does not deploy (WildFly 14.0.1)
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11084?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-11084:
-----------------------------------------
I'll defer to the EJB experts and/or [~swd847] as to whether lookup requires some special behavior.
In general though if the server has the data to detect a problem that would result in app failure, it should use it.
> inter-app quickstart does not deploy (WildFly 14.0.1)
> -----------------------------------------------------
>
> Key: WFLY-11084
> URL: https://issues.jboss.org/browse/WFLY-11084
> Project: WildFly
> Issue Type: Bug
> Reporter: Kevin Eagles
> Assignee: Bartosz Baranowski
> Priority: Critical
>
> Using Wildfly 14.0.1.Final
> When deploying inter-app-appA.war, Wildfly complains about the EJB lookup for:
> @ejb(lookup = "java:global/inter-app-appB/BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar")
> Likewise, when deploying inter-app-appB.war, Wildfly complains about the EJB lookup for:
> @ejb(lookup = "java:global/inter-app-appA/FooImpl!org.jboss.as.quickstarts.interapp.shared.Foo")
> To reproduce, from the inter-app quickstart:
> mvn install wildfly:deploy
> Can also reproduce by just doing an mvn install, then manually deploying the jar, then appA, then appB using the HAL Management Console.
> {noformat}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "inter-app-appA.war")]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
> }
> 09:56:51,014 ERROR [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0021: Deploy of deployment "inter-app-appA.war" was rolled back with the following failure message:
> {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\""],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.inter-app-appA.inter-app-appA.env.\"org.jboss.as.quickstarts.interapp.appA.Imports\".bar is missing [jboss.naming.context.java.global.inter-app-appB.\"BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar\"]"]
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-2968) Improve stateless ksession throughput performance
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-2968?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-2968:
--------------------------------
Fix Version/s: 7.13.0.Final
> Improve stateless ksession throughput performance
> -------------------------------------------------
>
> Key: DROOLS-2968
> URL: https://issues.jboss.org/browse/DROOLS-2968
> Project: Drools
> Issue Type: Feature Request
> Reporter: Mark Proctor
> Assignee: Mario Fusco
> Priority: Major
> Labels: MDP_BRAINFARTS
> Fix For: 7.13.0.Final
>
>
> Stateless access has become too heavy. We should look at streamlining the api, to avoid unnecessary work, and unnecessary (on demand) object creation. For example we know if rules need timers, avoid the timer creation if not necessary.
> Also we should look at (with evaluation first) to determine if a Three local cache of ksessions, with reset, will help improve GC impact.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11143) Message sent to JMSReplyTo from old client does not find correct binding
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11143?page=com.atlassian.jira.plugin... ]
Miroslav Novak edited comment on WFLY-11143 at 10/11/18 9:49 AM:
-----------------------------------------------------------------
[~martyn-taylor] Even [~ehugonnet]] has fixed the prefixes then I think workaround cannot help in this case. MDB is consuming message from InQueue and it does not know if it was sent by old/new client. Thus when it processes the message and sends response to reply queue then it does not know if prefix should be used or not.
was (Author: mnovak):
[~martyn-taylor] Even [~eeshet] has fixed the prefixes then I think workaround cannot help in this case. MDB is consuming message from InQueue and it does not know if it was sent by old/new client. Thus when it processes the message and sends response to reply queue then it does not know if prefix should be used or not.
> Message sent to JMSReplyTo from old client does not find correct binding
> ------------------------------------------------------------------------
>
> Key: WFLY-11143
> URL: https://issues.jboss.org/browse/WFLY-11143
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
>
> There is regression in backward compatibility of messaging client. JMSReplyTo destination set by older client contains incorrect address which causes that reply message does not have correct binding and such message is lost.
> Impact: Applications will stop work after upgrade to WF14/EAP 7.2.0.CD14.
> Test Scenario:
> * Start EAP 7.2.0.CD14/WF14 server (Artemis 2.x) with deployed InQueue and OutQueue
> * Send message to InQueue from older EAP 7.2.0.CD13/WF13/Artemis 1.5.5 client to InQueue. Message has JMSReplyTo header set to OutQueue. Client got "OutQueue" queue from JNDI lookup from EAP7.2.0.CD14/WF14
> * Deploy MDB to server
> ** MDB consumes message from InQueue and sends new message to destination defined in JMSReplyTo header (so to OutQueue)
> * Receive message from OutQueue
> Result:
> No message is received from OutQueue. There is debug message in server log:
> {code}
> 11:36:09,565 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (Thread-25 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@22848193)) Message CoreMessage[m
> essageID=214,durable=true,userID=c0de8bd0-cba6-11e8-840f-f496342f6705,priority=4, timestamp=Tue Oct 09 11:36:09 CEST 2018,expiration=0, durable=true, address=jms.queue.OutQueue,size=580,properties=TypedPropertie
> s[inMessageId=ID:c0383a39-cba6-11e8-95ad-f496342f6705,__AMQ_CID=c0d9349a-cba6-11e8-840f-f496342f6705,_AMQ_DUPL_ID=90d1e80e-116d-4eef-9513-84c6085549db,_AMQ_ROUTING_TYPE=0]]@1680840457 is not going anywhere as it
> didn't have a binding on address:jms.queue.OutQueue
> {code}
> which indicates that jms.queue.OutQueue address does not have a binding.
> The same happesn if older EAP/WF server (with Artemis 1.5.5x) is used and new EAP 7.2.0.CD14/WF14(Artemis 2.x) client is used.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11143) Message sent to JMSReplyTo from old client does not find correct binding
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-11143?page=com.atlassian.jira.plugin... ]
Miroslav Novak commented on WFLY-11143:
---------------------------------------
[~martyn-taylor] Even [~eeshet] has fixed the prefixes then I think workaround cannot help in this case. MDB is consuming message from InQueue and it does not know if it was sent by old/new client. Thus when it processes the message and sends response to reply queue then it does not know if prefix should be used or not.
> Message sent to JMSReplyTo from old client does not find correct binding
> ------------------------------------------------------------------------
>
> Key: WFLY-11143
> URL: https://issues.jboss.org/browse/WFLY-11143
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
>
> There is regression in backward compatibility of messaging client. JMSReplyTo destination set by older client contains incorrect address which causes that reply message does not have correct binding and such message is lost.
> Impact: Applications will stop work after upgrade to WF14/EAP 7.2.0.CD14.
> Test Scenario:
> * Start EAP 7.2.0.CD14/WF14 server (Artemis 2.x) with deployed InQueue and OutQueue
> * Send message to InQueue from older EAP 7.2.0.CD13/WF13/Artemis 1.5.5 client to InQueue. Message has JMSReplyTo header set to OutQueue. Client got "OutQueue" queue from JNDI lookup from EAP7.2.0.CD14/WF14
> * Deploy MDB to server
> ** MDB consumes message from InQueue and sends new message to destination defined in JMSReplyTo header (so to OutQueue)
> * Receive message from OutQueue
> Result:
> No message is received from OutQueue. There is debug message in server log:
> {code}
> 11:36:09,565 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] (Thread-25 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@22848193)) Message CoreMessage[m
> essageID=214,durable=true,userID=c0de8bd0-cba6-11e8-840f-f496342f6705,priority=4, timestamp=Tue Oct 09 11:36:09 CEST 2018,expiration=0, durable=true, address=jms.queue.OutQueue,size=580,properties=TypedPropertie
> s[inMessageId=ID:c0383a39-cba6-11e8-95ad-f496342f6705,__AMQ_CID=c0d9349a-cba6-11e8-840f-f496342f6705,_AMQ_DUPL_ID=90d1e80e-116d-4eef-9513-84c6085549db,_AMQ_ROUTING_TYPE=0]]@1680840457 is not going anywhere as it
> didn't have a binding on address:jms.queue.OutQueue
> {code}
> which indicates that jms.queue.OutQueue address does not have a binding.
> The same happesn if older EAP/WF server (with Artemis 1.5.5x) is used and new EAP 7.2.0.CD14/WF14(Artemis 2.x) client is used.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3109) [DMN Designer] Add additional Properties to drill-down
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-3109?page=com.atlassian.jira.plugi... ]
Matteo Mortari commented on DROOLS-3109:
----------------------------------------
Yes
Let's go step by step.
In a Context Entry value, you could enter a LiteralExpression (hence you would choose the expression language, by default FEEL)
In a Function definition body, you could enter a LiteralExpression (hence you would choose the expression language, by default FEEL).
etc.
of those cases where the expression is a Literal Expression --as you mentioned.
For Decision Table cells also,
as Input Entry by the spec is always of type {{UnaryTests}} hence text itself of the expression + Expression language,
as Output Entry by the spec is always of type {{LiteralExpression}}.
In layman terms, they can only be text fields where you can enter some (normally FEEL) expression editor text.
For Relation cells also, as we've chosen to limit the type of expression used to LiteralExpression and hence ExpressionLanguage is available --as you mentioned.
> [DMN Designer] Add additional Properties to drill-down
> ------------------------------------------------------
>
> Key: DROOLS-3109
> URL: https://issues.jboss.org/browse/DROOLS-3109
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Priority: Critical
> Labels: drools-tools
>
> The Properties Panel currently shows properties for Stunner-level "graph" components.
> *Further to DROOLS-2804, that added the generic support for "drill down" and {{ExpressionLanguage}} on {{LiteralExpression}}, this JIRA is to add support for the remaining properties that should be rendered when a component is "drilled down".*
> h2. Properties on the Grid Level
> The selection on the grid level should show the properties below. Please notice that selection of multiple cells, rows or columns should show empty properties panel.
> (everything should have ID, Description properties. Components which inherit from "NamedElement" should also have Name property)
> h3. Literal expression
> ||Selected item||Properties panel items||type||
> |Cell|ExpressionLanguage|URI|
> h3. Context
> ||Selected item||Properties panel items||type||
> |Row|type Ref|ItemDefinition ref (same which applies to Key Cell|
> |Column|n/a|n/a|
> |Key Cell|type Ref|ItemDefinition ref|
> |Value Cell|ExpressionLanguage|URI|
> h3. Decision Table
> ||Selected item||Properties panel items||type||
> |Row|n/a|n/a|
> | Input Column|Constraints|Text field|
> |Output Column|Output values|Unary tests|
> |Output Column|Default Output|expression|
> |Cell|ExpressionLanguage|URI|
> h3. Relation
> ||Selected item||Properties panel items||type||
> |Row|n/a|n/a|
> |Column|type Ref|ItemDefinition ref|
> |Cell|ExpressionLanguage|URI|
> h3. Function
> ||Selected item||Properties panel items||type||
> |Row|n/a|n/a|
> |Column|n/a|n/a|
> |Cell|ExpressionLanguage|URI|
> h3. Invocation
> ||Selected item||Properties panel items||type||
> |Row|n/a|n/a|
> |Column|n/a|n/a|
> |Cell|ExpressionLanguage|URI|
> h2. Manual Acceptance Test
> - Switching between DRG and Grid editor, check proper fields shown
> - Switching between rows, columns, cells in Grid editor, check proper fields
> -- In same expression kind
> -- Across different expression kinds
> - Clear expression kind
> - Read only mode - older asset version
> - All Grid specific properties saved
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (ELY-1653) JDK 11 Support
by Justin Cook (Jira)
[ https://issues.jboss.org/browse/ELY-1653?page=com.atlassian.jira.plugin.s... ]
Justin Cook resolved ELY-1653.
------------------------------
Resolution: Done
> JDK 11 Support
> --------------
>
> Key: ELY-1653
> URL: https://issues.jboss.org/browse/ELY-1653
> Project: WildFly Elytron
> Issue Type: Task
> Components: Build
> Reporter: Darran Lofthouse
> Assignee: Justin Cook
> Priority: Major
> Labels: Java11
> Fix For: 1.7.0.CR3
>
>
> I suspect this will likely take three / four steps: -
> # Convert he project to a multi-release built using Java 9
> # Eliminate the use of APIs in sun.misc and sun.reflect in the Java 9 variant
> # Ensure the project can be build on JDK 11
> This final step may not be achievable in the short term until we can drop support for JDK 8 but by moving to the Java 9 MR jar our jar should be compatible on Java 10 and 11 as well. We may want to define a PR run that builds on Java 9 but tests in Java 11, this would mean the testsuite at least needs to be buildable on Java 11.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months