[JBoss JIRA] (WFLY-6808) DistributableSession validate method throw misleading exception message
by Mathieu Lachance (JIRA)
Mathieu Lachance created WFLY-6808:
--------------------------------------
Summary: DistributableSession validate method throw misleading exception message
Key: WFLY-6808
URL: https://issues.jboss.org/browse/WFLY-6808
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Mathieu Lachance
Assignee: Paul Ferraro
In DistributableSession the validate method is getting called for any underlying undertow session access to make sure we are not touching an already invalidated session (which totally make sense):
{code}
public class DistributableSession implements io.undertow.server.session.Session {
// These mechanisms can auto-reauthenticate and thus use local context (instead of replicating)
private static final Set<String> AUTO_REAUTHENTICATING_MECHANISMS = new HashSet<>(Arrays.asList(HttpServletRequest.BASIC_AUTH, HttpServletRequest.DIGEST_AUTH, HttpServletRequest.CLIENT_CERT_AUTH));
private static void validate(Session<LocalSessionContext> session) {
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionNotFound(session.getId());
}
}
}
{code}
The problem though is the exception message that is thrown is really misleading because in reality the session actually exists but is currently invalid and/or getting invalidated. This can happen especially when running in optimistic mode where we can have many differents threads accessing the very same session.
I would recommend we do instead:
{code}
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated();
}
{code}
or even better:
{code}
if (!session.isValid()) {
throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(session.getId());
}
{code}
but it will require also a change in Undertow to actually template/parametize the sessionAlreadyInvalidated message.
Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6200) connection-url is required even when not used
by Rich DiCroce (JIRA)
[ https://issues.jboss.org/browse/WFLY-6200?page=com.atlassian.jira.plugin.... ]
Rich DiCroce commented on WFLY-6200:
------------------------------------
No, it is not correct that connection-url is mandatory. You simply need to define the host and port as connection properties instead. Read the comments on WFLY-6157 and consult your JDBC driver's documentation for more info.
> connection-url is required even when not used
> ---------------------------------------------
>
> Key: WFLY-6200
> URL: https://issues.jboss.org/browse/WFLY-6200
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Lin Gao
>
> Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start:
> {noformat}
> 09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "GamingPortalDS")
> ]) - failure description: "WFLYCTL0155: connection-url may not be null"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6807) XA Datasource wizard does not add <xa-datasource-class> element in configuration when using deployed JDBC driver
by Anthony Vanelverdinghe (JIRA)
Anthony Vanelverdinghe created WFLY-6807:
--------------------------------------------
Summary: XA Datasource wizard does not add <xa-datasource-class> element in configuration when using deployed JDBC driver
Key: WFLY-6807
URL: https://issues.jboss.org/browse/WFLY-6807
Project: WildFly
Issue Type: Bug
Components: Web Console
Affects Versions: 10.0.0.Final
Reporter: Anthony Vanelverdinghe
Assignee: Harald Pehl
When creating an Oracle XA Datasource using the wizard in the Administration Console, and specifying a JDBC driver which was uploaded as a new deployment, the wizard does not add the element <xa-datasource-class> in the datasource configuration, which causes Test Connection to fail with: "WFLYJCA0040: failed to invoke operation: WFLYJCA0047: Connection is not valid", and the stack trace below.
The wizard ought to either ask to provide the class name, or inspect the .jar to find it by itself (I'd assume most JDBC drivers come with at most 1 implementation of javax.sql.XADataSource).
11:24:01,853 ERROR [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000906: Error during crash recovery: java:/XAOracleDS (IJ0310
84: Unable to create connection): javax.resource.ResourceException: IJ031084: Unable to create connection
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:509)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory$1$1.run(XAManagedConnectionFactory.java:395)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory$1$1.run(XAManagedConnectionFactory.java:392)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory$1.run(XAManagedConnectionFactory.java:391)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory$1.run(XAManagedConnectionFactory.java:388)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.createManagedConnection(XAManagedConnectionFactory.java:387)
at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.open(XAResourceRecoveryImpl.java:355)
at org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl.getXAResources(XAResourceRecoveryImpl.java:193)
at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:519)
at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:185)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:747)
at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:375)
Caused by: javax.resource.ResourceException: IJ031101: XADataSourceClass is undefined
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXADataSource(XAManagedConnectionFactory.java:621)
at org.jboss.jca.adapters.jdbc.xa.XAManagedConnectionFactory.getXAManagedConnection(XAManagedConnectionFactory.java:492)
... 15 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1639) Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1639?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-1639:
------------------------------------------
For Elytron development we are temporarily reverting the original commit to get us back up and running again: -
https://github.com/wildfly-security-incubator/wildfly-core/tree/WFCORE-1639
> Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1639
> URL: https://issues.jboss.org/browse/WFCORE-1639
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha4
>
>
> I am raising this immediately as a Blocker as the changes made for WFCORE-307 effectively prevent us from referencing Elytron supplied capabilities to secure the management interfaces.
> https://github.com/wildfly/wildfly-core/commit/13d8f51b79c8b976ec7a5489c9...
> I think at this point it would be easier to revert WFCORE-307 and re-evaluate.
> To provide consistency we have all been working along the path where Elytron can be configured using a subsystem and used in all modes of the server, this was even a big motivation for Kabir's work bringing subsystems to host controllers.
> We could take the view that only subsystems can depend on subsystems but I think we would quickly reach the point where we discuss moving management into a subsystem which would immediately obsolete the changes for WFCORE-307 - this move is something that has been talked about a number of times already.
> This will need discussion but as an alternative idea for the original issue reported in WFCORE-307, how about adding the ability to flag a select few capabilities as crtitical / core and those will always cause a failure in this first boot if their requirements are not satisfied.
> Also I think WFCORE-307 may only be a partial solution, if we are really saying the server can only run if it is manageable there is still the possibility that at stage RUNTIME the services will fail to start.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6200) connection-url is required even when not used
by Mickaël Vera (JIRA)
[ https://issues.jboss.org/browse/WFLY-6200?page=com.atlassian.jira.plugin.... ]
Mickaël Vera commented on WFLY-6200:
------------------------------------
Today with the current limitation, it is not possible to create a datasource on a server different from "localhost:5432" as connection-url is ignored. It is correct that connection-url is mandatory.
> connection-url is required even when not used
> ---------------------------------------------
>
> Key: WFLY-6200
> URL: https://issues.jboss.org/browse/WFLY-6200
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Lin Gao
>
> Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start:
> {noformat}
> 09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "GamingPortalDS")
> ]) - failure description: "WFLYCTL0155: connection-url may not be null"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6644) Provide container managed sign on in configuration of pooled-connection-factory
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-6644?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-6644:
----------------------------------------
We need to catch up at some point with you and discuss how we will integrate Elytron based security - the JAAS security domains are deprecated and we have a lot of changes coming regarding client side security configuration.
> Provide container managed sign on in configuration of pooled-connection-factory
> -------------------------------------------------------------------------------
>
> Key: WFLY-6644
> URL: https://issues.jboss.org/browse/WFLY-6644
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
>
> Currently it's not possible to configure container managed sign-on for Artemis RA in <pooled-connection-factory> in messaging-activemq subsystem. This will allow to provide authentication information when new connection to Artemis broker is created without specifying username and password when calling connectionFactory.createConnection().
> Such security-domain could look like:
> {code}<security-domain name="CrashRecoveryDomain0">
> <authentication>
> <login-module code="ConfiguredIdentity" flag="required">
> <module-option name="principal" value="crash0"/>
> <module-option name="password" value="crash0"/>
> <module-option name="password-stacking" value="useFirstPass"/>
> <module-option name="userName" value="crash0"/>
> </login-module>
> </authentication>
> </security-domain>{code}
> The main benefit is that username and password can be omitted when creating new connection and does not have to be hard cored in EJB/Servlet. This could be used for inbound connections as well. We should allow to specify default-principal-name which would be used for authentication. There is more info about this approach in WebLogic documentatin [1].
> [1] https://docs.oracle.com/cd/E13222_01/wls/docs92/resadapter/security.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6644) Provide container managed sign on in configuration of pooled-connection-factory
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6644?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6644:
-----------------------------------
ARTEMIS-617 is required to be able to use the credentials from the ConnectionRequestInfo even when the container-managed Subject is present
> Provide container managed sign on in configuration of pooled-connection-factory
> -------------------------------------------------------------------------------
>
> Key: WFLY-6644
> URL: https://issues.jboss.org/browse/WFLY-6644
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
>
> Currently it's not possible to configure container managed sign-on for Artemis RA in <pooled-connection-factory> in messaging-activemq subsystem. This will allow to provide authentication information when new connection to Artemis broker is created without specifying username and password when calling connectionFactory.createConnection().
> Such security-domain could look like:
> {code}<security-domain name="CrashRecoveryDomain0">
> <authentication>
> <login-module code="ConfiguredIdentity" flag="required">
> <module-option name="principal" value="crash0"/>
> <module-option name="password" value="crash0"/>
> <module-option name="password-stacking" value="useFirstPass"/>
> <module-option name="userName" value="crash0"/>
> </login-module>
> </authentication>
> </security-domain>{code}
> The main benefit is that username and password can be omitted when creating new connection and does not have to be hard cored in EJB/Servlet. This could be used for inbound connections as well. We should allow to specify default-principal-name which would be used for authentication. There is more info about this approach in WebLogic documentatin [1].
> [1] https://docs.oracle.com/cd/E13222_01/wls/docs92/resadapter/security.html
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1639) Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1639?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-1639:
-------------------------------------
Description:
I am raising this immediately as a Blocker as the changes made for WFCORE-307 effectively prevent us from referencing Elytron supplied capabilities to secure the management interfaces.
https://github.com/wildfly/wildfly-core/commit/13d8f51b79c8b976ec7a5489c9...
I think at this point it would be easier to revert WFCORE-307 and re-evaluate.
To provide consistency we have all been working along the path where Elytron can be configured using a subsystem and used in all modes of the server, this was even a big motivation for Kabir's work bringing subsystems to host controllers.
We could take the view that only subsystems can depend on subsystems but I think we would quickly reach the point where we discuss moving management into a subsystem which would immediately obsolete the changes for WFCORE-307 - this move is something that has been talked about a number of times already.
This will need discussion but as an alternative idea for the original issue reported in WFCORE-307, how about adding the ability to flag a select few capabilities as crtitical / core and those will always cause a failure in this first boot if their requirements are not satisfied.
Also I think WFCORE-307 may only be a partial solution, if we are really saying the server can only run if it is manageable there is still the possibility that at stage RUNTIME the services will fail to start.
was:
I am raising this immediately as a Blocker as the changes made for WFCORE-307 effectively prevent us from referencing Elytron supplied capabilities to secure the management interfaces.
I think at this point it would be easier to revert WFCORE-307 and re-evaluate.
To provide consistency we have all been working along the path where Elytron can be configured using a subsystem and used in all modes of the server, this was even a big motivation for Kabir's work bringing subsystems to host controllers.
We could take the view that only subsystems can depend on subsystems but I think we would quickly reach the point where we discuss moving management into a subsystem which would immediately obsolete the changes for WFCORE-307 - this move is something that has been talked about a number of times already.
This will need discussion but as an alternative idea for the original issue reported in WFCORE-307, how about adding the ability to flag a select few capabilities as crtitical / core and those will always cause a failure in this first boot if their requirements are not satisfied.
Also I think WFCORE-307 may only be a partial solution, if we are really saying the server can only run if it is manageable there is still the possibility that at stage RUNTIME the services will fail to start.
> Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1639
> URL: https://issues.jboss.org/browse/WFCORE-1639
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha4
>
>
> I am raising this immediately as a Blocker as the changes made for WFCORE-307 effectively prevent us from referencing Elytron supplied capabilities to secure the management interfaces.
> https://github.com/wildfly/wildfly-core/commit/13d8f51b79c8b976ec7a5489c9...
> I think at this point it would be easier to revert WFCORE-307 and re-evaluate.
> To provide consistency we have all been working along the path where Elytron can be configured using a subsystem and used in all modes of the server, this was even a big motivation for Kabir's work bringing subsystems to host controllers.
> We could take the view that only subsystems can depend on subsystems but I think we would quickly reach the point where we discuss moving management into a subsystem which would immediately obsolete the changes for WFCORE-307 - this move is something that has been talked about a number of times already.
> This will need discussion but as an alternative idea for the original issue reported in WFCORE-307, how about adding the ability to flag a select few capabilities as crtitical / core and those will always cause a failure in this first boot if their requirements are not satisfied.
> Also I think WFCORE-307 may only be a partial solution, if we are really saying the server can only run if it is manageable there is still the possibility that at stage RUNTIME the services will fail to start.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1639) Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1639:
----------------------------------------
Summary: Causing the process to terminate before subsystems are processed prevents management depending on subsystem provided capabilities.
Key: WFCORE-1639
URL: https://issues.jboss.org/browse/WFCORE-1639
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Brian Stansberry
Priority: Blocker
Fix For: 3.0.0.Alpha4
I am raising this immediately as a Blocker as the changes made for WFCORE-307 effectively prevent us from referencing Elytron supplied capabilities to secure the management interfaces.
I think at this point it would be easier to revert WFCORE-307 and re-evaluate.
To provide consistency we have all been working along the path where Elytron can be configured using a subsystem and used in all modes of the server, this was even a big motivation for Kabir's work bringing subsystems to host controllers.
We could take the view that only subsystems can depend on subsystems but I think we would quickly reach the point where we discuss moving management into a subsystem which would immediately obsolete the changes for WFCORE-307 - this move is something that has been talked about a number of times already.
This will need discussion but as an alternative idea for the original issue reported in WFCORE-307, how about adding the ability to flag a select few capabilities as crtitical / core and those will always cause a failure in this first boot if their requirements are not satisfied.
Also I think WFCORE-307 may only be a partial solution, if we are really saying the server can only run if it is manageable there is still the possibility that at stage RUNTIME the services will fail to start.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JGRP-2020) Remove demos and tests packages from final artifact
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2020?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2020:
--------------------------------
I want to release only a single JAR, not 3. First, the size is currently 2MB, very small. And second, when doing consulting, I always need to diagnostics tools, which would not be present, so they have to be downloaded tediously.
However, I don't mind removing all unit tests *except* the classes in tests/other and tests/perf. If you submit a PR that does this in pom.xml, I'll accept it.
> Remove demos and tests packages from final artifact
> ---------------------------------------------------
>
> Key: JGRP-2020
> URL: https://issues.jboss.org/browse/JGRP-2020
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.6.6
> Environment: Wildfly 10.0.0.Final
> Reporter: Mathieu Lachance
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Would it be possible to remove unecessary (I assume) demos and tests packages from the final built artifact.
> Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months