December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9640) Configuring deployment runtime name with XML

by dbdbdb dbdbdb (JIRA)

[ https://issues.jboss.org/browse/WFLY-9640?page=com.atlassian.jira.plugin.... ] dbdbdb dbdbdb updated WFLY-9640: -------------------------------- Description: In my opinion, Wildfly should have an option to define the name and runtime name of a web application (.war) in a XML file. Like jboss-web.xml and ejb-jar.xml, it would be great if we could set the runtime name in a XML whatever the .war filename is. It would be very useful, not only to prevent human error when deploying via web console (filling the upload form with wrong runtime name), but also when the applications are deployed by copying the .war file into deployments directory. The correct runtime name is important because Wildfly uses this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was previously serialized. was: Wildfly should have a option to define the name and runtime name of a web application (.war) in a XML file. Like jboss-web.xml and ejb-jar.xml, it would be great if we can set the runtime name in a XML whatever the .war filename is. Very useful not only to prevent human error when deploying via web console (fill the upload form with wrong runtime name), but also useful when the applications is deployed by copying the .war file into deployments directory. The correct runtime name is important because Wildfly use this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was serialized before. > Configuring deployment runtime name with XML > -------------------------------------------- > > Key: WFLY-9640 > URL: https://issues.jboss.org/browse/WFLY-9640 > Project: WildFly > Issue Type: Feature Request > Components: Application Client, Server > Affects Versions: 10.1.0.Final, 11.0.0.Final > Reporter: dbdbdb dbdbdb > Assignee: Stuart Douglas > > In my opinion, Wildfly should have an option to define the name and runtime name of a web application (.war) in a XML file. > Like jboss-web.xml and ejb-jar.xml, it would be great if we could set the runtime name in a XML whatever the .war filename is. It would be > very useful, not only to prevent human error when deploying via web console (filling the upload form with wrong runtime name), but also when the applications are deployed by copying the .war file into deployments directory. > The correct runtime name is important because Wildfly uses this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was previously serialized. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9640) Configuring deployment runtime name with XML

by dbdbdb dbdbdb (JIRA)

dbdbdb dbdbdb created WFLY-9640: ----------------------------------- Summary: Configuring deployment runtime name with XML Key: WFLY-9640 URL: https://issues.jboss.org/browse/WFLY-9640 Project: WildFly Issue Type: Feature Request Components: Application Client, Server Affects Versions: 11.0.0.Final, 10.1.0.Final Reporter: dbdbdb dbdbdb Assignee: Stuart Douglas Wildfly should have a option to define the name and runtime name of a web application (.war) in a XML file. Like jboss-web.xml and ejb-jar.xml, it would be great if we can set the runtime name in a XML whatever the .war filename is. Very useful not only to prevent human error when deploying via web console (fill the upload form with wrong runtime name), but also useful when the applications is deployed by copying the .war file into deployments directory. The correct runtime name is important because Wildfly use this name for object serialization (Infinispan, JMS, etc). And if the runtime name changes, Wildfly can't deserialize objects when it was serialized before. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9639) Messages are stuck in a Queue that is configured on HornetQ

by Rajendra Mallampati (JIRA)

Rajendra Mallampati created WFLY-9639: ----------------------------------------- Summary: Messages are stuck in a Queue that is configured on HornetQ Key: WFLY-9639 URL: https://issues.jboss.org/browse/WFLY-9639 Project: WildFly Issue Type: Bug Components: Application Client Affects Versions: 9.x.x TBD Environment: RHEL 7.2, JDK 1.8_144 Reporter: Rajendra Mallampati Assignee: Stuart Douglas We use WildFly 9.0.2 for hosting our web application and it has both real time and batch processing components. One of the functions supported on the web includes uploading a file with a number of lines any where from 1 to 10K, If the file is valid (virus scan etc passed) it is parsed into that may messages and published to a queue. Each message will have two counters total number of messages that are published to the queue, and the message number. The consuming side is implemented using Spring DefaultMessageListenerContainer (DMLC) with a concurrency of 50 and maxConcurrency of 75. The listeners that implement MessageListener interface are integrated into DMLC. sometimes, if the producing side published 100 messages the consuming side only receiving 98 (per say) and gets stuck because two more messages should be in the Queue. Those two messages are not delivered and don't know where they are going. We tried even persistent Queues and the result is same (getting stuck). This is happening in production and any insight into this issue is highly appreciated. Here are the software details: App server : Wildfly 9.0.2 HornetQ : 2.4.7 JDK : 1_8_144 If you need additional details I will be very glad to provide. Thanks Rajendra -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9638) Remove uses of "new OperationFailedException(ModelNode)"

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9638: -------------------------------------- Summary: Remove uses of "new OperationFailedException(ModelNode)" Key: WFLY-9638 URL: https://issues.jboss.org/browse/WFLY-9638 Project: WildFly Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Constructor is deprecated; remove use of it so we can eventually drop it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3481) Remove uses of "new OperationFailedException(ModelNode)"

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3481?page=com.atlassian.jira.plugi... ] Brian Stansberry moved WFLY-9638 to WFCORE-3481: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-3481 (was: WFLY-9638) Component/s: Domain Management (was: Domain Management) > Remove uses of "new OperationFailedException(ModelNode)" > -------------------------------------------------------- > > Key: WFCORE-3481 > URL: https://issues.jboss.org/browse/WFCORE-3481 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > Constructor is deprecated; remove use of it so we can eventually drop it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3481) Remove uses of "new OperationFailedException(ModelNode)"

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3481?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3481: ------------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/10731) > Remove uses of "new OperationFailedException(ModelNode)" > -------------------------------------------------------- > > Key: WFCORE-3481 > URL: https://issues.jboss.org/browse/WFCORE-3481 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > Constructor is deprecated; remove use of it so we can eventually drop it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9637) Remove uses of "new OperationFailedException(ModelNode)"

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9637: -------------------------------------- Summary: Remove uses of "new OperationFailedException(ModelNode)" Key: WFLY-9637 URL: https://issues.jboss.org/browse/WFLY-9637 Project: WildFly Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Constructor is deprecated; remove use of it so we can eventually drop it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2199) Rule units are executed in reverse order when a consequence calls a sequence of drools.run(unit)

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2199?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-2199. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/a1d778bcb93658f98ab0bac10a520dc... > Rule units are executed in reverse order when a consequence calls a sequence of drools.run(unit) > ------------------------------------------------------------------------------------------------ > > Key: DROOLS-2199 > URL: https://issues.jboss.org/browse/DROOLS-2199 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2199) Rule units are executed in reverse order when a consequence calls a sequence of drools.run(unit)

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-2199: ----------------------------------- Summary: Rule units are executed in reverse order when a consequence calls a sequence of drools.run(unit) Key: DROOLS-2199 URL: https://issues.jboss.org/browse/DROOLS-2199 Project: Drools Issue Type: Bug Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ELY-1472) [native kerberos] setting channelBinding of gssContext when not used

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1472?page=com.atlassian.jira.plugin.s... ] Jan Kalina closed ELY-1472. --------------------------- Resolution: Rejected Fixing patch of JDK in ELY-283: https://issues.jboss.org/secure/attachment/12429366/jkalina-openjdk-nativ... Closing this, as this is not Elytron issue actually. > [native kerberos] setting channelBinding of gssContext when not used > -------------------------------------------------------------------- > > Key: ELY-1472 > URL: https://issues.jboss.org/browse/ELY-1472 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.2.0.Beta11 > Reporter: Jan Kalina > Assignee: Jan Kalina > Labels: kerberos > > Gs2SaslServer: gssContext's channelBinding setting leads to error when native Kerberos is used. > This lead to following error when using native Kerberos library: > {code} > [GSSLibStub_acceptContext] before2: pCred=35810112, pContext=0 > [GSSLibStub_acceptContext] before3: inToken.length=515 > [GSSLibStub_acceptContext] after: pCred=35810112, pContext=0, pDelegCred=0 > [GSSLibStub_acceptContext] after2: major=262144, GSS_ERROR(major)=262144 minor=12 > [GSSLibStub_acceptContext] acceptSecContext JK Status major/minor = 40000/12 > c/r/s = 0/4/0 > {code} > Which mean routine error 4 has occurred, which is GSS_S_BAD_BINDINGS - Incorrect channel bindings were supplied. > This is fixed when I change cb (in native) to GSS_C_NO_CHANNEL_BINDINGS - equivalent of setting null into channelBinding in gssContext. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2017