[JBoss JIRA] (WFLY-11146) org.apache.activemq.artemis.journal module should not depend on org.apache.activemq.artemis
by Jeff Mesnil (Jira)
Jeff Mesnil created WFLY-11146:
----------------------------------
Summary: org.apache.activemq.artemis.journal module should not depend on org.apache.activemq.artemis
Key: WFLY-11146
URL: https://issues.jboss.org/browse/WFLY-11146
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 14.0.0.Final
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
While looking at Weld dependency, Jean-Francois found the dependency chain:
/org.jboss.as.weld/org.jboss.weld.core/javax.ejb.api/javax.rmi.api/javax.orb.api/org.wildfly.iiop-openjdk/org.jboss.jts/org.apache.activemq.artemis.journal/org.apache.activemq.artemis
org.jboss.jts dependency to org.apache.activemq.artemis.journal is correct as Naryana uses Artemis journal for its transaction log.
However org.apache.activemq.artemis.journal should not depend on org.apache.activemq.artemis. It depends on it for the artemis-commons jar (as explained in https://github.com/wildfly/wildfly/blob/47b1db08fadb745706df7ba411db4f725... but code should be refactored so that this dependency is no longer required).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11144) Remove javax.ejb.api module dependency on javax.rmi.api
by David Lloyd (Jira)
[ https://issues.jboss.org/browse/WFLY-11144?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFLY-11144:
------------------------------------
Running {{jdeps}} seems to confirm that this is OK:
{noformat}
$ jdeps ~/.m2/repository/org/jboss/spec/javax/ejb/jboss-ejb-api_3.2_spec/1.0.1.Final/jboss-ejb-api_3.2_spec-1.0.1.Final.jar
jboss-ejb-api_3.2_spec-1.0.1.Final.jar -> java.base
jboss-ejb-api_3.2_spec-1.0.1.Final.jar -> java.naming
jboss-ejb-api_3.2_spec-1.0.1.Final.jar -> java.rmi
jboss-ejb-api_3.2_spec-1.0.1.Final.jar -> not found
javax.ejb -> java.io java.base
javax.ejb -> java.lang java.base
javax.ejb -> java.lang.annotation java.base
javax.ejb -> java.rmi java.rmi
javax.ejb -> java.security java.base
javax.ejb -> java.util java.base
javax.ejb -> java.util.concurrent java.base
javax.ejb -> javax.transaction not found
javax.ejb -> javax.xml.rpc.handler not found
javax.ejb.embeddable -> java.io java.base
javax.ejb.embeddable -> java.lang java.base
javax.ejb.embeddable -> java.net java.base
javax.ejb.embeddable -> java.util java.base
javax.ejb.embeddable -> java.util.regex java.base
javax.ejb.embeddable -> javax.ejb jboss-ejb-api_3.2_spec-1.0.1.Final.jar
javax.ejb.embeddable -> javax.ejb.spi jboss-ejb-api_3.2_spec-1.0.1.Final.jar
javax.ejb.embeddable -> javax.naming java.naming
javax.ejb.spi -> java.io java.base
javax.ejb.spi -> java.lang java.base
javax.ejb.spi -> java.util java.base
javax.ejb.spi -> javax.ejb jboss-ejb-api_3.2_spec-1.0.1.Final.jar
javax.ejb.spi -> javax.ejb.embeddable jboss-ejb-api_3.2_spec-1.0.1.Final.jar
{noformat}
I don't see any dependencies that would have to come from {{javax.rmi.api}}.
> Remove javax.ejb.api module dependency on javax.rmi.api
> -------------------------------------------------------
>
> Key: WFLY-11144
> URL: https://issues.jboss.org/browse/WFLY-11144
> Project: WildFly
> Issue Type: Task
> Components: EJB
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
>
> The javax.ejb.api module depends on javax.rmi.api. But I can't see any reason why; the code in the spec jar does not import anything from any of the classes in the javax.rmi and org.jboss.javax.rmi packages that the javax.rmi.api module exports.
> This is important because javax.rmi.api brings in a huge dependency tree. That module is really just a wrapper around javax.orb.api, exporting a subset of its packages. And javax.orb.api is a misnomer -- it's not just API, it's the entire orb, with implementation dependencies that transitively bring in a large chunk of the entire appserver codebase.
> So if javax.ejb.api does not need javax.rmi.api we need to remove that link.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3067) [DMN Designer] Automatic Layout Feature Workbench Integration
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3067?page=com.atlassian.jira.plugi... ]
Jozef Marko commented on DROOLS-3067:
-------------------------------------
[~dadossan] I agree, no prompt needed for that case when everything is in the [0,0] coordinate.
However I did first manual check with the [^DMCommunity Challenge - March 2017.dmn] and there is this issue. If I open that model without your algorithm, all nodes are connected to one graph. If I open that model with your algorithm, nodes are split to two separate graphs. Could you please have a look?
> [DMN Designer] Automatic Layout Feature Workbench Integration
> -------------------------------------------------------------
>
> Key: DROOLS-3067
> URL: https://issues.jboss.org/browse/DROOLS-3067
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: DMCommunity Challenge - March 2017.dmn
>
>
> Integrate the Automatic Layout feature into workbench, so during opening an imported DMN model its nodes are positioned automatically with this feature.
> h2. Acceptance tests
> # User is prompted if he wants or not to apply autolayout feature
> # Positioning is automatically stored after model opening
> # Simple graph, no branches, starting node on left, ending node on right
> # Simple graph, no branches, starting node on bottom, ending node on top
> # Tree, top node in the middle of the screen, some branches to all sides
> # Graph with big crossing of edges, similar to complete graph
> # Large (but sparse) graph, not all nodes visible without scrolling
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3067) [DMN Designer] Automatic Layout Feature Workbench Integration
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3067?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3067:
--------------------------------
Description:
Integrate the Automatic Layout feature into workbench, so during opening an imported DMN model its nodes are positioned automatically with this feature.
h2. Acceptance tests
# -User is prompted if he wants or not to apply autolayout feature- discussed in comments
# Positioning is automatically stored after model opening
# Simple graph, no branches, starting node on left, ending node on right
# Simple graph, no branches, starting node on bottom, ending node on top
# Tree, top node in the middle of the screen, some branches to all sides
# Graph with big crossing of edges, similar to complete graph
# Large (but sparse) graph, not all nodes visible without scrolling
was:
Integrate the Automatic Layout feature into workbench, so during opening an imported DMN model its nodes are positioned automatically with this feature.
h2. Acceptance tests
# User is prompted if he wants or not to apply autolayout feature
# Positioning is automatically stored after model opening
# Simple graph, no branches, starting node on left, ending node on right
# Simple graph, no branches, starting node on bottom, ending node on top
# Tree, top node in the middle of the screen, some branches to all sides
# Graph with big crossing of edges, similar to complete graph
# Large (but sparse) graph, not all nodes visible without scrolling
> [DMN Designer] Automatic Layout Feature Workbench Integration
> -------------------------------------------------------------
>
> Key: DROOLS-3067
> URL: https://issues.jboss.org/browse/DROOLS-3067
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: DMCommunity Challenge - March 2017.dmn
>
>
> Integrate the Automatic Layout feature into workbench, so during opening an imported DMN model its nodes are positioned automatically with this feature.
> h2. Acceptance tests
> # -User is prompted if he wants or not to apply autolayout feature- discussed in comments
> # Positioning is automatically stored after model opening
> # Simple graph, no branches, starting node on left, ending node on right
> # Simple graph, no branches, starting node on bottom, ending node on top
> # Tree, top node in the middle of the screen, some branches to all sides
> # Graph with big crossing of edges, similar to complete graph
> # Large (but sparse) graph, not all nodes visible without scrolling
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3067) [DMN Designer] Automatic Layout Feature Workbench Integration
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3067?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3067:
--------------------------------
Attachment: DMCommunity Challenge - March 2017.dmn
> [DMN Designer] Automatic Layout Feature Workbench Integration
> -------------------------------------------------------------
>
> Key: DROOLS-3067
> URL: https://issues.jboss.org/browse/DROOLS-3067
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Attachments: DMCommunity Challenge - March 2017.dmn
>
>
> Integrate the Automatic Layout feature into workbench, so during opening an imported DMN model its nodes are positioned automatically with this feature.
> h2. Acceptance tests
> # User is prompted if he wants or not to apply autolayout feature
> # Positioning is automatically stored after model opening
> # Simple graph, no branches, starting node on left, ending node on right
> # Simple graph, no branches, starting node on bottom, ending node on top
> # Tree, top node in the middle of the screen, some branches to all sides
> # Graph with big crossing of edges, similar to complete graph
> # Large (but sparse) graph, not all nodes visible without scrolling
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JBLOGGING-133) Support specification of existing logging provider other than by system property.
by James Perkins (Jira)
[ https://issues.jboss.org/browse/JBLOGGING-133?page=com.atlassian.jira.plu... ]
James Perkins commented on JBLOGGING-133:
-----------------------------------------
One idea I had too was to use a custom service loader that would look for the known class names. My main issue with that was it would require knowledge of the internal class names.
> Support specification of existing logging provider other than by system property.
> ---------------------------------------------------------------------------------
>
> Key: JBLOGGING-133
> URL: https://issues.jboss.org/browse/JBLOGGING-133
> Project: JBoss Logging
> Issue Type: Feature Request
> Components: jboss-logging-spi
> Reporter: Steven Sharp
> Assignee: James Perkins
> Priority: Major
>
> The only way to choose a logging provider other than jboss is by using the {{org.jboss.logging.provider}} system property. There are cases where this is not feasible or even possible. Since using the service loader method is not a supported solution, there needs to be an alternative to the system property for selecting a different logging provider.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JBLOGGING-133) Support specification of existing logging provider other than by system property.
by David Lloyd (Jira)
[ https://issues.jboss.org/browse/JBLOGGING-133?page=com.atlassian.jira.plu... ]
David Lloyd commented on JBLOGGING-133:
---------------------------------------
A possible approach could be to read a jboss-logging.properties file which can specify a built-in provider name. It could also be used for other primordial items, like establishing a default locale that differs from the platform.
> Support specification of existing logging provider other than by system property.
> ---------------------------------------------------------------------------------
>
> Key: JBLOGGING-133
> URL: https://issues.jboss.org/browse/JBLOGGING-133
> Project: JBoss Logging
> Issue Type: Feature Request
> Components: jboss-logging-spi
> Reporter: Steven Sharp
> Assignee: James Perkins
> Priority: Major
>
> The only way to choose a logging provider other than jboss is by using the {{org.jboss.logging.provider}} system property. There are cases where this is not feasible or even possible. Since using the service loader method is not a supported solution, there needs to be an alternative to the system property for selecting a different logging provider.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JBLOGGING-133) Support specification of existing logging provider other than by system property.
by David Lloyd (Jira)
[ https://issues.jboss.org/browse/JBLOGGING-133?page=com.atlassian.jira.plu... ]
David Lloyd commented on JBLOGGING-133:
---------------------------------------
A risk is that it is a sure thing that people will confuse {{jboss-logging.properties}} with {{jboss-logmanager.properties}}.
> Support specification of existing logging provider other than by system property.
> ---------------------------------------------------------------------------------
>
> Key: JBLOGGING-133
> URL: https://issues.jboss.org/browse/JBLOGGING-133
> Project: JBoss Logging
> Issue Type: Feature Request
> Components: jboss-logging-spi
> Reporter: Steven Sharp
> Assignee: James Perkins
> Priority: Major
>
> The only way to choose a logging provider other than jboss is by using the {{org.jboss.logging.provider}} system property. There are cases where this is not feasible or even possible. Since using the service loader method is not a supported solution, there needs to be an alternative to the system property for selecting a different logging provider.
--
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] it's not possible to configure and try possible workaround with anycast/multicast prefixes as messaging subsystem does not allow to set them atm. This should be addressed in WFLY-11145.
> 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-11135) Object, instead of a simple boolean should be returned by stop operation on mod_cluster
by Paul Ferraro (Jira)
[ https://issues.jboss.org/browse/WFLY-11135?page=com.atlassian.jira.plugin... ]
Paul Ferraro closed WFLY-11135.
-------------------------------
Resolution: Rejected
Rejecting. This is a new operation, which has no requirement to conform to the output format of its legacy equivalent, so long as compatibility is preserved (which is the case).
> Object, instead of a simple boolean should be returned by stop operation on mod_cluster
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-11135
> URL: https://issues.jboss.org/browse/WFLY-11135
> Project: WildFly
> Issue Type: Bug
> Components: mod_cluster
> Affects Versions: 14.0.0.Final
> Reporter: Jan Kašík
> Assignee: Radoslav Husar
> Priority: Minor
>
> When calling {{stop}} operation, object should be returned:
> {code}
> [standalone@127.0.0.1:9990 /] /subsystem=modcluster/proxy=default:stop()
> {
> "outcome" => "success",
> "result" => {"session-draining-complete" => true}
> }
> {code}
> Instead, just boolean is returned:
> {code}
> [standalone@127.0.0.1:9990 /] /subsystem=modcluster/proxy=default:stop()
> {
> "outcome" => "success",
> "result" => true
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months