September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1831) Build XML parser from a resource's pathElement

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFCORE-1831: ----------------------------------- Summary: Build XML parser from a resource's pathElement Key: WFCORE-1831 URL: https://issues.jboss.org/browse/WFCORE-1831 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Affects Versions: 3.0.0.Alpha8 Reporter: Jeff Mesnil Assignee: Brian Stansberry The current PersistentResourceXMLBuilder API requires to pass a ResourceDefinition to build the XML representation to parse and marshall. This requires to provides static ResourceDefinition which may be impratical if the resource model can be affected by the runtime state. The PersistentResourceXMLDescription only relies on the resourceDefinition's pathElement to know the "name" of the resource. The list of attributes to map to XML is provided explicitly to the builder. The PersistentResourceXMLBuilder API should be modified to use only a PathElement and remove its reference to resourceDefinition. For compatibility the current builder method with PersistentResourceDefinition must be kept and delegate to the new one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1831) Build XML parser from a resource's pathElement

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1831?page=com.atlassian.jira.plugi... ] Jeff Mesnil reassigned WFCORE-1831: ----------------------------------- Assignee: Tomaz Cerar (was: Brian Stansberry) > Build XML parser from a resource's pathElement > ---------------------------------------------- > > Key: WFCORE-1831 > URL: https://issues.jboss.org/browse/WFCORE-1831 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Affects Versions: 3.0.0.Alpha8 > Reporter: Jeff Mesnil > Assignee: Tomaz Cerar > > The current PersistentResourceXMLBuilder API requires to pass a ResourceDefinition to build the XML representation to parse and marshall. This requires to provides static ResourceDefinition which may be impratical if the resource model can be affected by the runtime state. > The PersistentResourceXMLDescription only relies on the resourceDefinition's pathElement to know the "name" of the resource. The list of attributes to map to XML is provided explicitly to the builder. > The PersistentResourceXMLBuilder API should be modified to use only a PathElement and remove its reference to resourceDefinition. > For compatibility the current builder method with PersistentResourceDefinition must be kept and delegate to the new one. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7202) generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7202?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7202: ----------------------------------------------- Tom Ross <tom.ross(a)redhat.com> changed the Status of [bug 1379571|https://bugzilla.redhat.com/show_bug.cgi?id=1379571] from NEW to CLOSED > generic-jms-ra's JmsMCFProperties.getSessionDefaultType returns incorrect value for session type > ------------------------------------------------------------------------------------------------ > > Key: WFLY-7202 > URL: https://issues.jboss.org/browse/WFLY-7202 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.1.0.Final > Reporter: Tom Ross > Assignee: Tom Ross > > The code snippet shows that the method returns wrong type. > {noformat} > public String getSessionDefaultType() { > if (type == JmsConnectionFactory.AGNOSTIC) > return "agnostic"; > else if (type == JmsConnectionFactory.QUEUE) > return TOPIC_TYPE; > else > return QUEUE_TYPE; > } > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions

by Michał Nowakowski (JIRA)

Michał Nowakowski created WFLY-7229: --------------------------------------- Summary: WFLYCLWEBUT0001 for server-side invalidated sessions Key: WFLY-7229 URL: https://issues.jboss.org/browse/WFLY-7229 Project: WildFly Issue Type: Feature Request Components: Web (Undertow) Affects Versions: 10.1.0.Final Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes. Reporter: Michał Nowakowski Assignee: Stuart Douglas Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following: - a session is assigned (or created, if none existed before) - its details are printed and the browser is told to refresh after 20 seconds - before the browser refreshes, the session is invalidated server-side by separate thread. Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors: - The first stacktrace happens when the thread invalidates the session. - The second stacktrace happens, when the browser refreshes. The user sees "Error 500". - The, after a minute or so, I get the last one. It then repeats periodically. We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7228) Improve wording in logging message for key WFLYWELD0013

by Gunnar Morling (JIRA)

[ https://issues.jboss.org/browse/WFLY-7228?page=com.atlassian.jira.plugin.... ] Gunnar Morling updated WFLY-7228: --------------------------------- Summary: Improve wording in logging message for key WFLYWELD0013 (was: Improve wording in Weld logging message for key WFLYWELD0013) > Improve wording in logging message for key WFLYWELD0013 > ------------------------------------------------------- > > Key: WFLY-7228 > URL: https://issues.jboss.org/browse/WFLY-7228 > Project: WildFly > Issue Type: Enhancement > Reporter: Gunnar Morling > Assignee: Jason Greene > Priority: Minor > > I'm seeing this message: > {quote} > WFLYWELD0013: Deployment deployment "demo.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > {quote} > Apart from the repeated "deployment", the double negation makes it confusing, I reckon it should say something like that: > {quote} > WFLYWELD0013: Deployment "demo.war" contains CDI annotations but is not a bean archive (Found no beans.xml nor a class with bean defining annotations) > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7228) Improve wording in Weld logging message for key WFLYWELD0013

by Gunnar Morling (JIRA)

[ https://issues.jboss.org/browse/WFLY-7228?page=com.atlassian.jira.plugin.... ] Gunnar Morling updated WFLY-7228: --------------------------------- Priority: Minor (was: Major) > Improve wording in Weld logging message for key WFLYWELD0013 > ------------------------------------------------------------ > > Key: WFLY-7228 > URL: https://issues.jboss.org/browse/WFLY-7228 > Project: WildFly > Issue Type: Enhancement > Reporter: Gunnar Morling > Assignee: Jason Greene > Priority: Minor > > I'm seeing this message: > {quote} > WFLYWELD0013: Deployment deployment "demo.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) > {quote} > Apart from the repeated "deployment", the double negation makes it confusing, I reckon it should say something like that: > {quote} > WFLYWELD0013: Deployment "demo.war" contains CDI annotations but is not a bean archive (Found no beans.xml nor a class with bean defining annotations) > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7228) Improve wording in Weld logging message for key WFLYWELD0013

by Gunnar Morling (JIRA)

Gunnar Morling created WFLY-7228: ------------------------------------ Summary: Improve wording in Weld logging message for key WFLYWELD0013 Key: WFLY-7228 URL: https://issues.jboss.org/browse/WFLY-7228 Project: WildFly Issue Type: Enhancement Reporter: Gunnar Morling Assignee: Jason Greene I'm seeing this message: {quote} WFLYWELD0013: Deployment deployment "demo.war" contains CDI annotations but no bean archive was not found. (No beans.xml nor class with bean defining annotations) {quote} Apart from the repeated "deployment", the double negation makes it confusing, I reckon it should say something like that: {quote} WFLYWELD0013: Deployment "demo.war" contains CDI annotations but is not a bean archive (Found no beans.xml nor a class with bean defining annotations) {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-643) On the SSLContextBuilder support setUseCipherSuitesOrder

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-643?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-643: --------------------------- Summary: On the SSLContextBuilder support setUseCipherSuitesOrder (was: On the SSLContextBuilder support setUserCipherSuiteOrder) > On the SSLContextBuilder support setUseCipherSuitesOrder > -------------------------------------------------------- > > Key: ELY-643 > URL: https://issues.jboss.org/browse/ELY-643 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.1.0.Beta10 > > > Currently we hard code this value to 'true' which should remain the default as the OpenSSL style cipher suite selection includes preferred mechanism ordering - however it should be possible to override this and set it to false. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2038) RpcDipatcher: calls with CompletableFuture don't respect timeout

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2038?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2038: --------------------------- Description: When calling {{RpcDispatcher.callRemoteMethodsWithFuture()}}, a timeout passed via RequestOptions is not respected; calls don't timeout out if any of the members doesn't reply. (was: When calling {{RpsDispatcher.callRemoteMethodsWithFuture()}}, a timeout passed via RequestOptions is not respected; calls don't timeout out if any of the members doesn't reply.) > RpcDipatcher: calls with CompletableFuture don't respect timeout > ---------------------------------------------------------------- > > Key: JGRP-2038 > URL: https://issues.jboss.org/browse/JGRP-2038 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > When calling {{RpcDispatcher.callRemoteMethodsWithFuture()}}, a timeout passed via RequestOptions is not respected; calls don't timeout out if any of the members doesn't reply. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1018) PeriodicSizeRotatingFileHandler's are always replaced during boot

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1018?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1018: ------------------------------------------------- Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1266360|https://bugzilla.redhat.com/show_bug.cgi?id=1266360] from ON_QA to VERIFIED > PeriodicSizeRotatingFileHandler's are always replaced during boot > ----------------------------------------------------------------- > > Key: WFCORE-1018 > URL: https://issues.jboss.org/browse/WFCORE-1018 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.0.0.CR6 > > > A {{periodic-size-rotating-file-handler}} will be replaced during the subsystem add operation. This could be an issue with {{async-handler}}'s where the handler may see the old handler that was closed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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