November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3213) Make default-cache attribute of cache-container element optional

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3213?page=com.atlassian.jira.plugin.... ] Paul Ferraro resolved WFLY-3213. -------------------------------- Fix Version/s: 11.0.0.Alpha1 Resolution: Done Done as part of Infinispan capabilities work. > Make default-cache attribute of cache-container element optional > ---------------------------------------------------------------- > > Key: WFLY-3213 > URL: https://issues.jboss.org/browse/WFLY-3213 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > Not every cache container requires a default cache. We can make default-cache an optional attribute and only specify it where it makes sense. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2607) EJB 4.2.1 passivation compliance

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-2607?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-2607. ------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Done All child issues are fixed now. Thank you everybody! > EJB 4.2.1 passivation compliance > -------------------------------- > > Key: WFLY-2607 > URL: https://issues.jboss.org/browse/WFLY-2607 > Project: WildFly > Issue Type: Task > Components: EJB > Affects Versions: 8.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > This is a parent task to track individual issues relating to serialization of SFSB fields during passivation/replication. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7100) Add JGroups-based SingletonServiceBuilderFactory implementation

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7100?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-7100: ------------------------------------ https://github.com/bstansberry/wildfly/pull/45 > Add JGroups-based SingletonServiceBuilderFactory implementation > --------------------------------------------------------------- > > Key: WFLY-7100 > URL: https://issues.jboss.org/browse/WFLY-7100 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 11.0.0.Alpha1 > > > The singleton subsystem currently requires the Infinispan subsystem. To minimize the requirements for using the singleton subsystem within the context of the host-controller, we should reimplement singleton service using JGroups directly, instead of requiring an Infinispan cache. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7558) Replacing a deployment (which uses a different runtime name), starts using the filename as runtime-name

by Fake Lastname (JIRA)

Fake Lastname created WFLY-7558: ----------------------------------- Summary: Replacing a deployment (which uses a different runtime name), starts using the filename as runtime-name Key: WFLY-7558 URL: https://issues.jboss.org/browse/WFLY-7558 Project: WildFly Issue Type: Bug Components: Server, Web Console Affects Versions: 10.1.0.Final Environment: OS X client, wildfly domain is running on CentOS 7 Reporter: Fake Lastname Assignee: Jason Greene This is a two step problem. If an ear has been uploaded and configured to use a different runtime name that works and the domain uses the correct runtime name. If I replace the ear it doesn't have an input box to choose a new runtime name- yet it defaults the new runtime name to the filename that's being used to replace the deployment. I tried to workaround this by renaming my ear to the runtime name and using that to replace the existing deployment but that gives this exception: Cannot upload deployment: {"domain-failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"otherName.ear\")]' not found"} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7557) Singleton subsystem remove operation must require reload

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7557: ---------------------------------- Summary: Singleton subsystem remove operation must require reload Key: WFLY-7557 URL: https://issues.jboss.org/browse/WFLY-7557 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Since the add operation registers deployment unit processors, the remove operation must require a server reload. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7556) Infinispan subsystem remove operation must require reload

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7556: ---------------------------------- Summary: Infinispan subsystem remove operation must require reload Key: WFLY-7556 URL: https://issues.jboss.org/browse/WFLY-7556 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Since the add operation registers deployment unit processors, the remove operation must require a server reload. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6915) Mod cluster not working with non-root user

by Matias Rand (JIRA)

[ https://issues.jboss.org/browse/WFLY-6915?page=com.atlassian.jira.plugin.... ] Matias Rand commented on WFLY-6915: ----------------------------------- Right, digging a bit deeper into the outbound-socket-binding there is an option to set Source Port. When creating an outbound-socket-binding in the web GUI (the pop-up) you don't see an option to set the source port. However, when hitting save and looking at the newly created settings the source port is actually set to 0. I initially thought that meant 0 as in undefined, but it seems indeed to be 0. There is a default outbound-socket-binding called "mail-smtp" that also has source port set to 0. When using jboss-cli to see the outbound-socket-binding settings the "mail-smtp" binding is showing "undefined" for the source port, but my newly created binding is indeed showing 0. So, setting the source port in the binding to something above 1024 seems to work like a charm, running EAP as a non-root user. Thank you for pointing me in the right direction. > Mod cluster not working with non-root user > ------------------------------------------ > > Key: WFLY-6915 > URL: https://issues.jboss.org/browse/WFLY-6915 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 10.0.0.Final > Environment: OS's tested: > # Red Hat Enterprise Linux Server release 6.5 (Santiago) > # CentOS Linux release 7.2.1511 (Core) > *SELINUX*: Disabled > *IPTABLES/FIREWALLD: *disabled with no rules > #wildfly: 10.0.0.Final > #httpd: > httpd-2.2.15-31.el6_5.x86_64 > httpd-tools-2.2.15-31.el6_5.x86_64 > httpd-devel-2.2.15-31.el6_5.x86_64 > #modcluster/httpd version: 1.2.6 > Reporter: Rafael Pereira > Assignee: Radoslav Husar > > When I run wildfly with a non-root user(wildfly) mod_cluster won't work. I got this error: > 14:09:06,327 ERROR [org.jboss.modcluster] (UndertowEventHandlerAdapter - 1) MODCLUSTER000043: Failed to send INFO command to relatorios.sistemafieg.org.br/11.12.13.14:6666: Permission denied > This happens when I use port-offset>0 and run wildfly service. > However, if I run with root user, this error won't happen > Steps to reproduce > 1. Adding user > {code:shell} > groupadd -r wildfly > useradd -r -g wildfly -d /opt/wildfly -s /sbin/nologin wildfly > {code} > 2. use init.d or systemd script > {code:shell} > wildfly-10.0.0.Final/docs/contrib/scripts/init.d/wildfly-init-redhat.sh > {code} > 3. start wildfly and register proxy list and socket binding > {code:shell} > /socket-binding-group=ha-sockets/remote-destination-outbound-socket-binding=mod_cluster:add(port=6666,host=11.12.13.14) > /profile=ha/subsystem=modcluster/mod-cluster-config=configuration:write-attribute(name=proxies,value=[mod_cluster]) > {code} > 4. edit wildfly.conf > {code:shell} > JBOSS_HOME="/opt/wildfly/server" > JBOSS_USER=wildfly > JBOSS_MODE=domain > JBOSS_HOST_CONFIG=host.xml > JBOSS_CONSOLE_LOG="/var/log/wildfly/console.log" > JBOSS_OPTS="-Djboss.domain.base.dir=/opt/wildfly/config/domain -Djboss.bind.address.management=11.12.13.10 -Djboss.bind.address=11.12.13.10" > {code} > 5. edit httpd.conf > {code} > LoadModule slotmem_module modules/mod_slotmem.so > LoadModule manager_module modules/mod_manager.so > LoadModule proxy_cluster_module modules/mod_proxy_cluster.so > LoadModule advertise_module modules/mod_advertise.so > Listen 6666 > <VirtualHost *:6666> > <Location /> > Order deny,allow > Deny from all > Allow from 11.12.13 > </Location> > <Location /mcm> > SetHandler mod_cluster-manager > Order deny,allow > Allow from all > </Location> > KeepAliveTimeout 300 > MaxKeepAliveRequests 0 > Timeout 5400 > ProxyTimeout 5400 > EnableMCPMReceive On > ManagerBalancerName myCluster > ServerAdvertise Off > ErrorLog logs/cluster-error.log > CustomLog logs/cluster-access.log INFO > </VirtualHost> > {code} > 6. Run with service or systemctl command: *service wildfly start* > *Environment:* > OS's tested: > # Red Hat Enterprise Linux Server release 6.5 (Santiago) > # CentOS Linux release 7.2.1511 (Core) > *SELINUX*: Disabled > *IPTABLES/FIREWALLD: * disabled and no rules set > *wildfly:* 10.0.0.Final > *httpd:* > httpd-2.2.15-31.el6_5.x86_64 > httpd-tools-2.2.15-31.el6_5.x86_64 > httpd-devel-2.2.15-31.el6_5.x86_64 > *modcluster/httpd version:* 1.2.6 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7549) Component upgrade Hibernate Validator to 5.3.2.Final

by Guillaume Smet (JIRA)

[ https://issues.jboss.org/browse/WFLY-7549?page=com.atlassian.jira.plugin.... ] Guillaume Smet updated WFLY-7549: --------------------------------- Fix Version/s: (was: 10.2.0.Final) > Component upgrade Hibernate Validator to 5.3.2.Final > ---------------------------------------------------- > > Key: WFLY-7549 > URL: https://issues.jboss.org/browse/WFLY-7549 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Guillaume Smet > Assignee: Scott Marlow > > Hi, > Hibernate Validator can be upgraded to the latest stable: Hibernate Validator 5.3.2.Final. > API wise, there are very few changes except to features that were experimental. > See our migration guide for 5.3 here: https://developer.jboss.org/wiki/HibernateValidatorMigrationGuide#jive_co... > I'm working on validating the upgrade in WildFly and preparing a PR. > -- > Guillaume -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-736) Introduce LocalAuthenticationFactory concept and class

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-736?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-736: --------------------------------- It's possible that this entire approach is wrong and that we should instead create an isolated local authentication API which uses ServerAuthenticationContext directly based on what is detected from the user's AuthenticationContext. This must be considered. > Introduce LocalAuthenticationFactory concept and class > ------------------------------------------------------ > > Key: ELY-736 > URL: https://issues.jboss.org/browse/ELY-736 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: David Lloyd > > We have a way to handle incoming authentication requests from HTTP, SASL, and TLS sources. But we don't have an API to handle local server authentication. We should have a LocalAuthenticationFactory, which implements MechanismAuthenticationFactory for this purpose. > Using JAAS as a simple model, such an API would require a class that acts as the client's login context (similarly to LoginContext), which when activated, will use the user's local AuthenticationContext to configure the identity and credentials, and yield an SI after successful authentication. > Because there are many ways in which an authentication can take place, the authentication factory may have to be able to specify or restrict the range of acceptable credential types and algorithms, and even principal types. Actual local "mechanisms" might or might not be of use to accomplish this, by returning client login contexts which utilize different principal and credential strategies. > For JAAS compatibility, it may be useful to be able to use this API to create a JAAS LoginModule which can use the local authentication factory to perform JAAS logins, wrapping the SI inside the JAAS Subject in whichever way we decide is correct. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-736) Introduce LocalAuthenticationFactory concept and class

by David Lloyd (JIRA)

David Lloyd created ELY-736: ------------------------------- Summary: Introduce LocalAuthenticationFactory concept and class Key: ELY-736 URL: https://issues.jboss.org/browse/ELY-736 Project: WildFly Elytron Issue Type: Task Components: API / SPI Reporter: David Lloyd We have a way to handle incoming authentication requests from HTTP, SASL, and TLS sources. But we don't have an API to handle local server authentication. We should have a LocalAuthenticationFactory, which implements MechanismAuthenticationFactory for this purpose. Using JAAS as a simple model, such an API would require a class that acts as the client's login context (similarly to LoginContext), which when activated, will use the user's local AuthenticationContext to configure the identity and credentials, and yield an SI after successful authentication. Because there are many ways in which an authentication can take place, the authentication factory may have to be able to specify or restrict the range of acceptable credential types and algorithms, and even principal types. Actual local "mechanisms" might or might not be of use to accomplish this, by returning client login contexts which utilize different principal and credential strategies. For JAAS compatibility, it may be useful to be able to use this API to create a JAAS LoginModule which can use the local authentication factory to perform JAAS logins, wrapping the SI inside the JAAS Subject in whichever way we decide is correct. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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