October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1876) Content completion does not work for deployment-info --headers

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1876?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1876: ---------------------------------------- Assignee: Jean-Francois Denise > Content completion does not work for deployment-info --headers > -------------------------------------------------------------- > > Key: WFCORE-1876 > URL: https://issues.jboss.org/browse/WFCORE-1876 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Bartosz Baranowski > Assignee: Jean-Francois Denise > Priority: Minor > > [standalone@localhost:9990 /] deployment-info --headers > [standalone@localhost:9990 /] deployment-info --headers=<TAB><TAB> > this does not kick in, should be: > [standalone@localhost:9990 /] deployment-info --headers={ > after first <TAB> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1335) Classpath is not checked for Kie Module ReleaseId

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1335?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-1335: ------------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Classpath is not checked for Kie Module ReleaseId > ------------------------------------------------- > > Key: DROOLS-1335 > URL: https://issues.jboss.org/browse/DROOLS-1335 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 6.4.0.Final, 6.5.0.CR2, 7.0.0.Beta2 > Reporter: Chadi El Masri > Assignee: Mario Fusco > Attachments: 0001-Implement-the-method-to-read-the-KieModule-from-clas.patch > > > Injecting a ksession annotated with a particular @KReleaseId is not able to read the passed release id from the classpath (the part that does that is not implemented). > The bug is here: https://github.com/droolsjbpm/drools/blob/6.4.0.Final/drools-compiler/src... > Patch attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7348) Elytron deployment depends on org.jboss.security.negotiation

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFLY-7348?page=com.atlassian.jira.plugin.... ] Martin Choma moved JBEAP-6510 to WFLY-7348: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-7348 (was: JBEAP-6510) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR6) > Elytron deployment depends on org.jboss.security.negotiation > ------------------------------------------------------------ > > Key: WFLY-7348 > URL: https://issues.jboss.org/browse/WFLY-7348 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > > Based on wildfly documentation deployment which is secured by SPNEGO have to depend on {{org.jboss.security.negotiation}} module > Such configuration leads to WARN message beeing logged into server log > {code} > 08:35:05,388 WARN [org.jboss.as.dependency.private] (MSC service thread 1-8) WFLYSRV0018: Deployment "deployment.secured-webapp.war" is using a private module ("org.jboss.security.negotiation:main") which may be changed or removed in future versions without notice. > {code} > [1] https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1878) CLI should not rely on values that could conflict with shell operators

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1878?page=com.atlassian.jira.plugi... ] Jean-Francois Denise reassigned WFCORE-1878: -------------------------------------------- Assignee: Jean-Francois Denise > CLI should not rely on values that could conflict with shell operators > ---------------------------------------------------------------------- > > Key: WFCORE-1878 > URL: https://issues.jboss.org/browse/WFCORE-1878 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt > Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1878) CLI should not rely on values that could conflict with shell operators

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1878: -------------------------------------------- Summary: CLI should not rely on values that could conflict with shell operators Key: WFCORE-1878 URL: https://issues.jboss.org/browse/WFCORE-1878 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Jean-Francois Denise If we move to a new CLI implementation that relies on Aesh Command parsing, then we will need to activate Aesh operator parsing to handle the following case: ls -l > output.txt Today, the deploy command makes use of <ALL> as a well known value to refer to all disabled deployment items. This will conflict with Aesh parser. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2119) Separate JMX objects

by Bela Ban (JIRA)

Bela Ban created JGRP-2119: ------------------------------ Summary: Separate JMX objects Key: JGRP-2119 URL: https://issues.jboss.org/browse/JGRP-2119 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 Provide managed attributes or operations in separate classes, e.g. to be used for stats in TP. These could include num_msgs_sent, num_batches_received etc. A protocol could implement an interface (e.g. AdditionalStats), which would return a list of objects whose attributes and operations should be exposed together with the protocol. This would reduce code in TP. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2118) TP: messages tagged with DONT_BUNDLE are not bundled

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2118?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2118. ---------------------------- Resolution: Done > TP: messages tagged with DONT_BUNDLE are not bundled > ---------------------------------------------------- > > Key: JGRP-2118 > URL: https://issues.jboss.org/browse/JGRP-2118 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Since 3.x (3.6?), *all* messages are bundled, even the ones tagged with DONT_BUNDLE. > This is incorrect and a regression from 3.x. > Fix: bundle _all_ messages. The DONT_BUNDLE and OOB flags only come into play at the receiver side where messages tagged with these flags are removed from a batch and delivered individually (in separate threads). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2118) TP: messages tagged with DONT_BUNDLE are not bundled

by Bela Ban (JIRA)

Bela Ban created JGRP-2118: ------------------------------ Summary: TP: messages tagged with DONT_BUNDLE are not bundled Key: JGRP-2118 URL: https://issues.jboss.org/browse/JGRP-2118 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 Since 3.x (3.6?), *all* messages are bundled, even the ones tagged with DONT_BUNDLE. This is incorrect and a regression from 3.x. Fix: bundle _all_ messages. The DONT_BUNDLE and OOB flags only come into play at the receiver side where messages tagged with these flags are removed from a batch and delivered individually (in separate threads). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1335) Classpath is not checked for Kie Module ReleaseId

by Chadi El Masri (JIRA)

Chadi El Masri created DROOLS-1335: -------------------------------------- Summary: Classpath is not checked for Kie Module ReleaseId Key: DROOLS-1335 URL: https://issues.jboss.org/browse/DROOLS-1335 Project: Drools Issue Type: Bug Components: kie server Affects Versions: 7.0.0.Beta2, 6.5.0.CR2, 6.4.0.Final Reporter: Chadi El Masri Assignee: Edson Tirelli Attachments: 0001-Implement-the-method-to-read-the-KieModule-from-clas.patch Injecting a ksession annotated with a particular @KReleaseId is not able to read the passed release id from the classpath (the part that does that is not implemented). The bug is here: https://github.com/droolsjbpm/drools/blob/6.4.0.Final/drools-compiler/src... Patch attached. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2117) TP: messages to self are not batched

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2117?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2117: -------------------------------- Hmm, the downside is that, whereas the current impl loops back message directly, using a bundler means that the messages would be marshalled and then unmarshalled. We should create a MessageBatch for looped-back messages without having to marshal/unmarshal. > TP: messages to self are not batched > ------------------------------------ > > Key: JGRP-2117 > URL: https://issues.jboss.org/browse/JGRP-2117 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > If A sends 100 multicast messages (or unicast messages to self), the messages to self are not batched but looped back individually, each using a separate thread from the thread pool. > So in the above case, A will receive its own 100 messages using 100 threads from the pool. > It would be more efficient to batch the 100 messages into a batch and then loop the batch back, taking up 1 thread instead of 100! > To do this, looping back has to be done _after_ the bundler, when the bundler is sending the message batch. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 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 October 2016