[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
[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
[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
[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
[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