January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFBUILD-32) Add support for hard coded artifact versions in module.xml

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFBUILD-32?page=com.atlassian.jira.plugin... ] Stuart Douglas resolved WFBUILD-32. ----------------------------------- Fix Version/s: 1.2.6.Final Resolution: Done > Add support for hard coded artifact versions in module.xml > ---------------------------------------------------------- > > Key: WFBUILD-32 > URL: https://issues.jboss.org/browse/WFBUILD-32 > Project: WildFly Build Tools > Issue Type: Feature Request > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 1.2.6.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-32) Add support for hard coded artifact versions in module.xml

by Stuart Douglas (JIRA)

Stuart Douglas created WFBUILD-32: ------------------------------------- Summary: Add support for hard coded artifact versions in module.xml Key: WFBUILD-32 URL: https://issues.jboss.org/browse/WFBUILD-32 Project: WildFly Build Tools Issue Type: Feature Request Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9674) Missing wrapper 'license' tag around full-feature-pack-licenses.xml entry for LGPL for artemis-wildfly-integration

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9674: -------------------------------------- Summary: Missing wrapper 'license' tag around full-feature-pack-licenses.xml entry for LGPL for artemis-wildfly-integration Key: WFLY-9674 URL: https://issues.jboss.org/browse/WFLY-9674 Project: WildFly Issue Type: Bug Components: Build System Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor $subject says it all. The EAP branch doesn't have this issue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-758) ClassNotFoundException: javax.sql.RowSet

by Greg Jewell (JIRA)

[ https://issues.jboss.org/browse/WFCORE-758?page=com.atlassian.jira.plugin... ] Greg Jewell closed WFCORE-758. ------------------------------ > ClassNotFoundException: javax.sql.RowSet > ---------------------------------------- > > Key: WFCORE-758 > URL: https://issues.jboss.org/browse/WFCORE-758 > Project: WildFly Core > Issue Type: Bug > Components: Modules > Environment: Windows 7, Java 8u45 (64 bit) > Reporter: Greg Jewell > Assignee: David Lloyd > Fix For: 1.0.0.CR7, 2.0.0.Alpha5 > > > I downloaded the WF9 CR2 release this morning and have been testing functionality. A new exception has appeared with this release. This did not happen with a source release that was downloaded and built between CR1 and CR2, so was just introduced in the last week or so. > We have a Flex application that is throwing the following exception as it's being loaded: > [BlazeDS]javax/sql/RowSet > {noformat} > java.lang.NoClassDefFoundError: javax/sql/RowSet > at flex.messaging.io.amf.Amf3Output.writeObject(Amf3Output.java:198) > at flex.messaging.messages.AbstractMessage.writeExternal(AbstractMessage.java:444) > at flex.messaging.messages.AsyncMessage.writeExternal(AsyncMessage.java:140) > at flex.messaging.messages.AcknowledgeMessage.writeExternal(AcknowledgeMessage.java:94) > at flex.messaging.messages.AcknowledgeMessageExt.writeExternal(AcknowledgeMessageExt.java:55) > at flex.messaging.io.amf.Amf3Output.writePropertyProxy(Amf3Output.java:594) > at flex.messaging.io.amf.Amf3Output.writeCustomObject(Amf3Output.java:532) > at flex.messaging.io.amf.Amf3Output.writeObject(Amf3Output.java:112) > at flex.messaging.io.amf.Amf0Output.writeObject(Amf0Output.java:206) > at flex.messaging.io.amf.AmfMessageSerializer.writeObject(AmfMessageSerializer.java:196) > at flex.messaging.io.amf.AmfMessageSerializer.writeBody(AmfMessageSerializer.java:186) > at flex.messaging.io.amf.AmfMessageSerializer.writeMessage(AmfMessageSerializer.java:142) > at flex.messaging.endpoints.amf.SerializationFilter.invoke(SerializationFilter.java:198) > at flex.messaging.endpoints.BaseHTTPEndpoint.service(BaseHTTPEndpoint.java:291) > at flex.messaging.MessageBrokerServlet.service(MessageBrokerServlet.java:353) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > Caused by: java.lang.ClassNotFoundException: javax.sql.RowSet from [Module "deployment.Test.ear.test.war:main" from Service Module Loader] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130) > ... 43 more > {noformat} > - See more at: https://developer.jboss.org/thread/260451#sthash.LJ3DCVsa.dpuf -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3447) CLI SSL security commands.

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3447?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-3447: ----------------------------------------- Description: In order to help configure SSL server side security, a set of CLI commands should be defined to drive users to realise the main use cases: - enable / disable SSL for management interfaces - enable / disable SSL for web server. These commands rely on the new elytron operations to manage key-store. was: In order to help configure server side security, a set of CLI commands should be defined to drive users to realise the main use cases: - SSL keystore management - SSL/HTTPS enablement/disablement - SASL/HTTP authentication (based on certificate). Analysis docs, work in progress: https://developer.jboss.org/wiki/SSLCommandsForCLI and https://developer.jboss.org/wiki/AuthenticationCommandsForCLI > CLI SSL security commands. > -------------------------- > > Key: WFCORE-3447 > URL: https://issues.jboss.org/browse/WFCORE-3447 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > In order to help configure SSL server side security, a set of CLI commands should be defined to drive users to realise the main use cases: > - enable / disable SSL for management interfaces > - enable / disable SSL for web server. > These commands rely on the new elytron operations to manage key-store. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3447) CLI SSL security commands.

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3447?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-3447: ----------------------------------------- Summary: CLI SSL security commands. (was: CLI security commands.) > CLI SSL security commands. > -------------------------- > > Key: WFCORE-3447 > URL: https://issues.jboss.org/browse/WFCORE-3447 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > In order to help configure server side security, a set of CLI commands should be defined to drive users to realise the main use cases: > - SSL keystore management > - SSL/HTTPS enablement/disablement > - SASL/HTTP authentication (based on certificate). > Analysis docs, work in progress: https://developer.jboss.org/wiki/SSLCommandsForCLI and https://developer.jboss.org/wiki/AuthenticationCommandsForCLI -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-8488: ------------------------------------ Yes, the data-source attribute is new as of WF11. e.g. {code:xml}<jdbc-protocol type="JDBC_PING" data-source="ExampleDS"/>{code} Prior to WF11, the protocol would need to supply a "datasource_jndi_name" property containing the JNDI name of a database. > Usage of JGroups JDBC_PING attempts to delete row too late > ---------------------------------------------------------- > > Key: WFLY-8488 > URL: https://issues.jboss.org/browse/WFLY-8488 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: John Ament > Assignee: Paul Ferraro > > I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down. > In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ] Paul Ferraro edited comment on WFLY-8488 at 1/15/18 11:24 AM: -------------------------------------------------------------- [~meetoblivion] Yes, the data-source attribute is new as of WF11. e.g. {code:xml}<jdbc-protocol type="JDBC_PING" data-source="ExampleDS"/>{code} Prior to WF11, the protocol would need to supply a "datasource_jndi_name" property containing the JNDI name of a database. was (Author: pferraro): Yes, the data-source attribute is new as of WF11. e.g. {code:xml}<jdbc-protocol type="JDBC_PING" data-source="ExampleDS"/>{code} Prior to WF11, the protocol would need to supply a "datasource_jndi_name" property containing the JNDI name of a database. > Usage of JGroups JDBC_PING attempts to delete row too late > ---------------------------------------------------------- > > Key: WFLY-8488 > URL: https://issues.jboss.org/browse/WFLY-8488 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: John Ament > Assignee: Paul Ferraro > > I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down. > In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9666) ClassLoader leak in org.jboss.el.cache.FactoryFinderCache (Wildfly 11)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9666?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-9666: ----------------------------------- We do have undeploy action to cleanup this https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss... But looking at this, it could not cleanup properly in EAR deployments. [~brunojcm] how does your deployment look like? > ClassLoader leak in org.jboss.el.cache.FactoryFinderCache (Wildfly 11) > ---------------------------------------------------------------------- > > Key: WFLY-9666 > URL: https://issues.jboss.org/browse/WFLY-9666 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 11.0.0.Final > Environment: macOS > Reporter: Bruno Medeiros > Assignee: Stuart Douglas > Priority: Critical > Attachments: Screen Shot 2018-01-14 at 19.32.10.png > > > I was investigating why my class loader was leaking and after fixing all the problems within my application classes I got the leak shown in the attachment. > !Screen Shot 2018-01-14 at 19.32.10.png|thumbnail! > This is pretty similar with WFLY-3365, not sure if I should have reopened that one o raised this one, sorry if I took the wrong decision. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9666) ClassLoader leak in org.jboss.el.cache.FactoryFinderCache (Wildfly 11)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9666?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-9666: ------------------------------ Description: I was investigating why my class loader was leaking and after fixing all the problems within my application classes I got the leak shown in the attachment. !Screen Shot 2018-01-14 at 19.32.10.png|thumbnail! This is pretty similar with WFLY-3365, not sure if I should have reopened that one o raised this one, sorry if I took the wrong decision. was: I was investigating why my class loader was leaking and after fixing all the problems within my application classes I got the leak shown in the attachment. !Screen Shot 2018-01-14 at 19.32.10.png|thumbnail! This is pretty similar with https://issues.jboss.org/browse/WFLY-3365, not sure if I should have reopened that one o raised this one, sorry if I took the wrong decision. > ClassLoader leak in org.jboss.el.cache.FactoryFinderCache (Wildfly 11) > ---------------------------------------------------------------------- > > Key: WFLY-9666 > URL: https://issues.jboss.org/browse/WFLY-9666 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 11.0.0.Final > Environment: macOS > Reporter: Bruno Medeiros > Assignee: Stuart Douglas > Priority: Critical > Attachments: Screen Shot 2018-01-14 at 19.32.10.png > > > I was investigating why my class loader was leaking and after fixing all the problems within my application classes I got the leak shown in the attachment. > !Screen Shot 2018-01-14 at 19.32.10.png|thumbnail! > This is pretty similar with WFLY-3365, not sure if I should have reopened that one o raised this one, sorry if I took the wrong decision. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 January 2018