December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5769) If development mode enabled register ProbeExtension also for non-web deployments

by Martin Kouba (JIRA)

Martin Kouba created WFLY-5769: ---------------------------------- Summary: If development mode enabled register ProbeExtension also for non-web deployments Key: WFLY-5769 URL: https://issues.jboss.org/browse/WFLY-5769 Project: WildFly Issue Type: Task Components: CDI / Weld Reporter: Martin Kouba Assignee: Martin Kouba Currently, the extension is only registered for web deployments. However, Weld Probe also supports JMX. See also {{org.jboss.as.weld.deployment.processors.DevelopmentModeProcessor}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5769) If development mode enabled register ProbeExtension also for non-web deployments

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-5769?page=com.atlassian.jira.plugin.... ] Martin Kouba updated WFLY-5769: ------------------------------- Affects Version/s: 10.0.0.CR4 > If development mode enabled register ProbeExtension also for non-web deployments > -------------------------------------------------------------------------------- > > Key: WFLY-5769 > URL: https://issues.jboss.org/browse/WFLY-5769 > Project: WildFly > Issue Type: Task > Components: CDI / Weld > Affects Versions: 10.0.0.CR4 > Reporter: Martin Kouba > Assignee: Martin Kouba > > Currently, the extension is only registered for web deployments. However, Weld Probe also supports JMX. See also {{org.jboss.as.weld.deployment.processors.DevelopmentModeProcessor}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2948) Welcome file does not work for *.jsf

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2948?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2948: ----------------------------------------------- Dmitrii Tikhomirov <dtikhomi(a)redhat.com> changed the Status of [bug 1256325|https://bugzilla.redhat.com/show_bug.cgi?id=1256325] from POST to ASSIGNED > Welcome file does not work for *.jsf > -------------------------------------- > > Key: WFLY-2948 > URL: https://issues.jboss.org/browse/WFLY-2948 > Project: WildFly > Issue Type: Bug > Components: Web (JBoss Web) > Affects Versions: 8.0.0.Final > Reporter: Gulam Samdani > Assignee: Remy Maucherat > Priority: Minor > Fix For: 8.1.0.CR1, 8.1.0.Final > > > Welcome file does not work for *.jsf > -------------------------------------------------------- > same problem not exists in Wildfly Beta but wildfly 8 final /cr1 gives this error ... > > problem : > > http://localhost:8080/hello ------------------------------ NO works*** > @http://localhost:8080/hello/index.jsf ------------- it works fine > ======================================= > <welcome-file-list> > > <welcome-file>index.jsf</welcome-file> > > </welcome-file-list> > <servlet> > <servlet-name>Faces Servlet</servlet-name> > <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > <servlet-mapping> > <servlet-name>Faces Servlet</servlet-name> > <url-pattern>*.jsf</url-pattern> > </servlet-mapping> > </web-app> > ------------------------------------------------- > Reproduce this error : > https://community.jboss.org/message/857300 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-203) Add OAuth2 SASL Mechanism

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-203?page=com.atlassian.jira.plugin.sy... ] Pedro Igor updated ELY-203: --------------------------- Description: See https://tools.ietf.org/html/rfc7628. (was: See https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-21.) > Add OAuth2 SASL Mechanism > ------------------------- > > Key: ELY-203 > URL: https://issues.jboss.org/browse/ELY-203 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SASL > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 2.0.0.Alpha1 > > > See https://tools.ietf.org/html/rfc7628. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5768) Unable to exclude root context (/) via excluded-contexts in mod_cluster subsystem

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-5768: ------------------------------------ Summary: Unable to exclude root context (/) via excluded-contexts in mod_cluster subsystem Key: WFLY-5768 URL: https://issues.jboss.org/browse/WFLY-5768 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR4 Reporter: Radoslav Husar Assignee: Radoslav Husar {noformat}[standalone@localhost:9990 /] /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=excluded-contexts,value="ROOT,/"{noformat} but no luck {noformat} mod_cluster/1.3.2.Alpha1-SNAPSHOT Auto Refresh show DUMP output show INFO output Node localhost (ajp://127.0.0.1:8009): Enable Contexts Disable Contexts Stop Contexts Balancer: syrah-cluster,LBGroup: ,Flushpackets: Off,Flushwait: 10000,Ping: 10000000,Smax: 26,Ttl: 60000000,Status: OK,Elected: 0,Read: 0,Transferred: 0,Connected: 0,Load: 77 Virtual Host 1: Contexts: /clusterbench-passivating, Status: ENABLED Request: 0 Disable Stop /, Status: ENABLED Request: 0 Disable Stop Aliases: localhost default-host {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5767) Fix reference to removed enable-welcome-root in welcome content

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-5767: ------------------------------------ Summary: Fix reference to removed enable-welcome-root in welcome content Key: WFLY-5767 URL: https://issues.jboss.org/browse/WFLY-5767 Project: WildFly Issue Type: Bug Components: Documentation, Web (Undertow) Affects Versions: 10.0.0.CR4 Reporter: Radoslav Husar Assignee: Radoslav Husar Priority: Trivial No more! - <p class="note">To replace this page set "enable-welcome-root" to false in your server configuration and deploy - your own war with / as its context path.</p> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1989 at 12/3/15 4:51 AM: --------------------------------------------------------- Another alternative is to always send the reusable buffer and copy at the {{TCP_NIO2}} level *if needed*. For example, if a write of 1000 bytes succeeds, then we know that 1000 bytes have been written and the buffer can get reused. If the write returns rc=800, then we know that we still need to write the final 200 bytes. In this case, we could *copy* the bytes in range {{buf[801..1000]}}. I assume that a TCP write would succeed in most cases, so this would not do a lot of copying. Downside: an NIO write is done deep inside JGroups NIO ({{NioConnection}}), so we'd have to let this class somehow know whether or not to copy data. For instance, if a user always provides copied data in the first place, there'd be no need o copy at all. was (Author: belaban): Another alternative is to always send the reusable buffer and copy at the {{TCP_NIO2}} level *if needed*. For example, if a write of 1000 bytes succeeds than we know that 1000 bytes have been written and the buffer can get reused. If the write returns rc=800, then we know that we still need to write the final 200 bytes. In this case, we could *copy* the bytes in range {{buf[801..1000]}}. I assume that a TCP write would succeed in most cases, so this would not do a lot of copying. Downside: an NIO write is done deep inside JGroups NIO ({{NioConnection}}), so we'd have to let this class somehow know whether or not to copy data. For instance, if a user always provides copied data in the first place, there'd be no need o copy at all. > Bundlers: reuse send buffer when transport == sync. > --------------------------------------------------- > > Key: JGRP-1989 > URL: https://issues.jboss.org/browse/JGRP-1989 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}. > Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer). > The code in the bundler should check for this, and copy if async or not copy if sync. > Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1989 at 12/3/15 4:50 AM: --------------------------------------------------------- If we use TCP, for instance and have no max_bundle_size, then we can get real huge buffers. This doesn't normally happen though, so perhaps - as you mentioned - I'll go with a copy for buffers greater than some predefined max size. was (Author: belaban): If we use TCP, for instance and have no max_bundle_size, then we can get real huge buffers. This doesn't noramlly happen though, so perhaps - as you mentioned - I'll go with a copy for buffers greater than some predefined max size. > Bundlers: reuse send buffer when transport == sync. > --------------------------------------------------- > > Key: JGRP-1989 > URL: https://issues.jboss.org/browse/JGRP-1989 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every message (or message list). This generates a lot of memory allocations, perhaps it is better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}. > Synchronous transports guarantee a message has been put on the wire when {{TP.send()}} returns, whereas asynchronous transports may only have completed a partial write (so we cannot reuse the buffer). > The code in the bundler should check for this, and copy if async or not copy if sync. > Whether or not a transport is sync is determined by a new abstract method that needs to be overridden by every transport. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5682) Can't define absolute path for object store location

by Ondřej Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-5682?page=com.atlassian.jira.plugin.... ] Ondřej Chaloupka commented on WFLY-5682: ---------------------------------------- Thanks for explanation [~bstansberry] and [~zhfeng] I do understand reasons and that I was wrong about understanding {{object-store-relative-to}} attribute. To be honest what I do not understand is if the initial issue could be resolved for EAP7. I mean could be possible to to give users ability to define transaction object store path by an absolute location? Even when model and compatibility would not be broken? Or all this have to be moved to let say EAP 7.1 and the JBEAP-1913 has to be marked as known issue for EAP7? > Can't define absolute path for object store location > ---------------------------------------------------- > > Key: WFLY-5682 > URL: https://issues.jboss.org/browse/WFLY-5682 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 10.0.0.CR4 > Reporter: Ondřej Chaloupka > Assignee: Amos Feng > Fix For: 10.0.0.CR5 > > > As trying to set absolute path for location of transaction log store I've got to suspicion that's not possible. > If I try to set `object-store-relative-to` to some absolute path or set `object-store-relative-to` to empty string and then `object-store-path` to some absolute path the server starts with exceptions [1][2]. > [1] > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745)Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/' > at org.jboss.as.controller.services.path.PathManagerService.resolveRelativePathEntry(PathManagerService.java:87) at org.jboss.as.txn.service.ArjunaObjectStoreEnvironmentService.start(ArjunaObjectStoreEnvironmentService.java:76) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ... > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.txn.ArjunaObjectStoreEnvironment" => "org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service > Caused by: java.lang.IllegalArgumentException: WFLYCTL0256: Could not find a path called '/home/ochaloup/tmp/'"}} > INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status reportWFLYCTL0186: Services which failed to start: service jboss.txn.ArjunaObjectStoreEnvironment: org.jboss.msc.service.StartException in service jboss.txn.ArjunaObjectStoreEnvironment: Failed to start service > {code} > [2] > {code} > ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration > at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) > at org.jboss.as.server.ServerService.boot(ServerService.java:356) at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) > at java.lang.Thread.run(Thread.java:745) > Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[348,13] > Message: "WFLYCTL0113: '' is an invalid value for parameter relative-to. Values must have a minimum length of 1 characters" > at org.jboss.as.controller.SimpleAttributeDefinition.parse(SimpleAttributeDefinition.java:161) at org.jboss.as.controller.SimpleAttributeDefinition.parseAndSetParameter(SimpleAttributeDefinition.java:186) > at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseObjectStoreEnvironmentElementAndEnrichOperation(TransactionSubsystem14Parser.java:205) > at org.jboss.as.txn.subsystem.TransactionSubsystem30Parser.readElement(TransactionSubsystem30Parser.java:67) at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:111) > at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:54) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547) > at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244) at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143) > at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69) at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47) at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) > ... 3 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1987) TransferQueueBundler: use ring buffer rather than linked queue

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1987?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1987. ---------------------------- Resolution: Done > TransferQueueBundler: use ring buffer rather than linked queue > -------------------------------------------------------------- > > Key: JGRP-1987 > URL: https://issues.jboss.org/browse/JGRP-1987 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.6.7 > > > {{LinkedBlockingQueue}} creates new entries for new elements, creating a steady memory churn. Use a fixed size array or ring buffer of {{capacity}} elements instead. > Possibly a new bundler implementation, to be able to contrast it to the existing one for performance. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 December 2015