February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8087) Statistics Resources are being created without a corresponding ManagementResourceRegistration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-8087?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-8087: ---------------------------------------- The resource-adapter resources will have the same issue on a server, but they don't on an HC. This is because RaAdd is only adding the statistics resource in performRuntime, which doesn't run on an HC. > Statistics Resources are being created without a corresponding ManagementResourceRegistration > --------------------------------------------------------------------------------------------- > > Key: WFLY-8087 > URL: https://issues.jboss.org/browse/WFLY-8087 > Project: WildFly > Issue Type: Bug > Components: JCA, JMS > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > While working on WFCORE-2286 I discovered that there are resources in the tree, at least on the DC, for which there is no corresponding MRR. I believe [~pferraro] in some recent work he's done has stumbled on a similar thing. > I found there were no MRRs for > /profile=*/subsystem=messaging-activemq/server=*/pooled-connection-factory=*/statistics=pool > /profile=*/subsystem=datasources/data-source=*/statistics=jdbc > /profile=*/subsystem=datasources/data-source=*/statistics=pool > I expect the latter two would be repeated for xa-data-source=* > Probably the lack of MRR is correct and the problem is the existence of the resource. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-945) User names in Elytron FileSystemRealm are not case sensitive on Windows

by Josef Cacek (JIRA)

Josef Cacek created ELY-945: ------------------------------- Summary: User names in Elytron FileSystemRealm are not case sensitive on Windows Key: ELY-945 URL: https://issues.jboss.org/browse/ELY-945 Project: WildFly Elytron Issue Type: Bug Reporter: Josef Cacek Assignee: Darran Lofthouse Priority: Blocker User names are case sensitive on Linux but not on Windows when using the Elytron {{FileSystemSecurityRealm}} This is IMO a security issue. And it also affects platform certifications. If this is by any chance an expected behavior, then it has to be emphasized in documentation and in the domain model too (description of file-system-realm) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2293) Centrally define sensitivity classifications for references to Elytron capabilities.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-2293: ------------------------------------------ Ok can add an elytron-domain-ref to give them a different meaning. > Centrally define sensitivity classifications for references to Elytron capabilities. > ------------------------------------------------------------------------------------ > > Key: WFCORE-2293 > URL: https://issues.jboss.org/browse/WFCORE-2293 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta1 > > > Predominantly the following 6 items are referenced across the application server: - > Authentication Context > Credential Store > HTTP Authentication Factory > SASL Authentication Factory > SSLContext > Security Domain > We should probably represent these as: - > (Authentication Context) -> Authentication Client Ref > (Credential Store) -> Credential > (HTTP / SASL Authentication Factory) -> Authentication Factory Ref > (Security Domain) -> Security Domain Ref > (SSL Context) -> SSL Ref > We already have 'Credential' defined so we can re-use that. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2293) Centrally define sensitivity classifications for references to Elytron capabilities.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugi... ] Darran Lofthouse edited comment on WFCORE-2293 at 2/13/17 3:06 PM: ------------------------------------------------------------------- Ok can add an elytron-security-domain-ref to give them a different meaning. was (Author: dlofthouse): Ok can add an elytron-domain-ref to give them a different meaning. > Centrally define sensitivity classifications for references to Elytron capabilities. > ------------------------------------------------------------------------------------ > > Key: WFCORE-2293 > URL: https://issues.jboss.org/browse/WFCORE-2293 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta1 > > > Predominantly the following 6 items are referenced across the application server: - > Authentication Context > Credential Store > HTTP Authentication Factory > SASL Authentication Factory > SSLContext > Security Domain > We should probably represent these as: - > (Authentication Context) -> Authentication Client Ref > (Credential Store) -> Credential > (HTTP / SASL Authentication Factory) -> Authentication Factory Ref > (Security Domain) -> Security Domain Ref > (SSL Context) -> SSL Ref > We already have 'Credential' defined so we can re-use that. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2293) Centrally define sensitivity classifications for references to Elytron capabilities.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2293: ------------------------------------------ That's a bit tricky as the old one had more of a "application security" meaning while security-realm-ref was for "management security". That is more a result of where the reference attribute is located though. The other thing is the names of legacy security domain names are possibly sensitive (I think; I know the old realms are), while the names of the new ones are not sensitive. So a valid restriction for the old ones will now unnecessarily affect the new ones. > Centrally define sensitivity classifications for references to Elytron capabilities. > ------------------------------------------------------------------------------------ > > Key: WFCORE-2293 > URL: https://issues.jboss.org/browse/WFCORE-2293 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta1 > > > Predominantly the following 6 items are referenced across the application server: - > Authentication Context > Credential Store > HTTP Authentication Factory > SASL Authentication Factory > SSLContext > Security Domain > We should probably represent these as: - > (Authentication Context) -> Authentication Client Ref > (Credential Store) -> Credential > (HTTP / SASL Authentication Factory) -> Authentication Factory Ref > (Security Domain) -> Security Domain Ref > (SSL Context) -> SSL Ref > We already have 'Credential' defined so we can re-use that. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2292) HTTPS / Native Management protocol mismatch when using SSL

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2292?page=com.atlassian.jira.plugi... ] Ken Wills commented on WFCORE-2292: ----------------------------------- [~darranl] Quick hack to get this working in core again, I doubt this is the way it's supposed to work, so I won't actually PR this. https://github.com/luck3y/wildfly-core/commit/6b8bd2b0c112333eba2cc5087c9... > HTTPS / Native Management protocol mismatch when using SSL > ---------------------------------------------------------- > > Key: WFCORE-2292 > URL: https://issues.jboss.org/browse/WFCORE-2292 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Ken Wills > Assignee: Ken Wills > > It looks like https://github.com/wildfly/wildfly-core/commit/77158040d82d74af33800fce88... may have introduced some soft or mismatch when trying to connect using SSL / TLS, the requested buffer size is quite large. > 1:30:58,377 TRACE [org.xnio.nio.selector] (management Accept) Beginning select on sun.nio.ch.EPollSelectorImpl@2ab25536 > 11:30:58,377 TRACE [org.xnio.listener] (management I/O-1) Invoking listener org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@aca44ee on channel org.xnio.conduits.ConduitStreamSourceChannel@787e0a1f > 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Not enough buffered bytes for message of size 369296128+4 (java.nio.DirectByteBuffer[pos=0 lim=135 cap=8192]) > ^^^^^^^ > 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Compacted existing buffer java.nio.DirectByteBuffer[pos=135 lim=8192 cap=8192] > 11:30:58,377 TRACE [org.jboss.remoting.remote.connection] (management I/O-1) Received EOF > 11:30:58,377 TRACE [org.jboss.remoting.remote] (management I/O-1) Received connection end-of-stream > 11:30:58,377 TRACE [org.xnio.nio.selector] (management I/O-1) Beginning select on sun.nio.ch.EPollSelectorImpl@1cc4241b > This was with native management, but I see the same thing using https. The client is jboss-cli.sh, connecting with: > ./bin/jboss-cli.sh -c --controller=127.0.0.1:9999 --user=admin --password=password > Relevant bits of config in use: > {quote} > <management> > <security-realms> > <security-realm name="sslSecurityRealm"> > <server-identities> > <ssl> > <keystore path="/home/kwills/ssl/configuration/server.keystore" alias="server" keystore-password="asdasd"/> > </ssl> > </server-identities> > <authentication> > <properties path="/home/kwills/ssl/configuration/users.properties" plain-text="true"/> > </authentication> > </security-realm> > </security-realms> > <management-interfaces> > <native-interface security-realm="sslSecurityRealm"> > <socket-binding native="native"/> > </native-interface> > </management-interfaces> > </management> > <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}"> > <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/> > <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/> > <socket-binding name="native" interface="management" port="${jboss.management.https.port:9999}"/> > </socket-binding-group> > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2293) Centrally define sensitivity classifications for references to Elytron capabilities.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-2293: ------------------------------------------ I think we can re-use the security-domain-ref as well although technically a different security domain they are similar. > Centrally define sensitivity classifications for references to Elytron capabilities. > ------------------------------------------------------------------------------------ > > Key: WFCORE-2293 > URL: https://issues.jboss.org/browse/WFCORE-2293 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta1 > > > Predominantly the following 6 items are referenced across the application server: - > Authentication Context > Credential Store > HTTP Authentication Factory > SASL Authentication Factory > SSLContext > Security Domain > We should probably represent these as: - > (Authentication Context) -> Authentication Client Ref > (Credential Store) -> Credential > (HTTP / SASL Authentication Factory) -> Authentication Factory Ref > (Security Domain) -> Security Domain Ref > (SSL Context) -> SSL Ref > We already have 'Credential' defined so we can re-use that. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8096) Outdated license file in infinispan JARs

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8096?page=com.atlassian.jira.plugin.... ] Radoslav Husar reassigned WFLY-8096: ------------------------------------ Assignee: Radoslav Husar (was: Paul Ferraro) > Outdated license file in infinispan JARs > ---------------------------------------- > > Key: WFLY-8096 > URL: https://issues.jboss.org/browse/WFLY-8096 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: Nikoleta Žiaková > Assignee: Radoslav Husar > > Infinispan JARs in EAP distribution contain LICENSE.txt file with LGPL 2.1. However, the correct license in version 8.2.5.Final is ASL 2.0 as stated in https://github.com/infinispan/infinispan/blob/8.2.5.Final/README.md and https://github.com/infinispan/infinispan/blob/8.2.5.Final/license/src/mai... > The Infinispan license changed in version 6.0.0 (ISPN-3292). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2293) Centrally define sensitivity classifications for references to Elytron capabilities.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2293?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2293: ------------------------------------- Description: Predominantly the following 6 items are referenced across the application server: - Authentication Context Credential Store HTTP Authentication Factory SASL Authentication Factory SSLContext Security Domain We should probably represent these as: - (Authentication Context) -> Authentication Client Ref (Credential Store) -> Credential (HTTP / SASL Authentication Factory) -> Authentication Factory Ref (Security Domain) -> Security Domain Ref (SSL Context) -> SSL Ref We already have 'Credential' defined so we can re-use that. was: Predominantly the following 6 items are referenced across the application server: - Authentication Context Credential Store HTTP Authentication Factory SASL Authentication Factory SSLContext Security Domain We should probably represent these as: - (Authentication Context) -> Client Security Ref (Credential Store) -> Credential (HTTP / SASL Authentication Factory) -> Authentication Factory Ref (Security Domain) -> Security Domain Ref (SSL Context) -> SSL Ref We already have 'Credential' defined so we can re-use that. > Centrally define sensitivity classifications for references to Elytron capabilities. > ------------------------------------------------------------------------------------ > > Key: WFCORE-2293 > URL: https://issues.jboss.org/browse/WFCORE-2293 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta1 > > > Predominantly the following 6 items are referenced across the application server: - > Authentication Context > Credential Store > HTTP Authentication Factory > SASL Authentication Factory > SSLContext > Security Domain > We should probably represent these as: - > (Authentication Context) -> Authentication Client Ref > (Credential Store) -> Credential > (HTTP / SASL Authentication Factory) -> Authentication Factory Ref > (Security Domain) -> Security Domain Ref > (SSL Context) -> SSL Ref > We already have 'Credential' defined so we can re-use that. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1548) Access denied when deploying to wildfly 10

by Joey Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1548?page=com.atlassian.jira.plugi... ] Joey Wang commented on WFCORE-1548: ----------------------------------- We have the same issue with Wildfly 10.1.0.Final in Windows Server 2016. We excluded the Wildfly folder from Windows Defender as workaround. Will this issue be fixed in Wildfly, or it is not a problem of Wildfly? > Access denied when deploying to wildfly 10 > ------------------------------------------ > > Key: WFCORE-1548 > URL: https://issues.jboss.org/browse/WFCORE-1548 > Project: WildFly Core > Issue Type: Bug > Environment: Wildfly 10, Windows 7, java 1.8_05, maven 3.0.5, maven 3.3.9 > Reporter: Srecko Mandelj > Assignee: James Perkins > Priority: Minor > Attachments: TestMavenPlugin.zip, server.log > > > I have a war application containing web services. I have no problems deploying war to wildfly 8.1. After upgrade to wildfly 10, the plugin doesn't work any more. I get this error when trying to deploy: > {code} > [Server:server-one] 09:36:51,162 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 132) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/ActivatorFrontEnd' > [Server:server-one] 09:36:51,220 SEVERE [javax.enterprise.resource.webcontainer. > jsf.config] (ServerService Thread Pool -- 132) Critical error during deployment: > : com.sun.faces.config.ConfigurationException: java.util.concurrent.ExecutionException: javax.faces.FacesException: java.io.FileNotFoundException: C:\podatki\jboss_configurations\wildfly10\domainController\servers\server-one\tmp\vfs\temp\temp1e3a1daf9121b0e4\content-34b685741ee5aeb4\content-6322725066713898564.tmp (Access is denied) > {code} > It looks like a concurrency issue - one process is trying to use a file that other process is using. If I deploy through web console or via CLI, I don't have this issue. It is somehow related to jsf implementation. If I remove jsf from wildfly configuration file (the module and subsystem), deploy works ok (Mojara is then not triggered and deploy is successful). > I tried to deploy with 1.1.9.Alpha8, but I get the same error. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 February 2017