December 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10894) [WFLY] Tests for enabling constraint drive authentication mode for elytron

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-10894?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-10894: --------------------------------- Fix Version/s: 15.0.0.Final > [WFLY] Tests for enabling constraint drive authentication mode for elytron > -------------------------------------------------------------------------- > > Key: WFLY-10894 > URL: https://issues.jboss.org/browse/WFLY-10894 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Bartosz Spyrko-Śmietanko > Priority: Major > Labels: test_included > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > Integration code for JBEAP-15054 > ---- > When elytron is enabled constraint driven authentication method (i.e. proactive-authentication=false) has no effect. > If you try to request an unsecured page sending in an invalid user with basic authentication, you should get the page returned with constraint drive authentication and a 401 with proactive authentication. This is what happens without Elytron enabled. But if you enable Elytron it gives a 401 in both cases. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11248) EJB Timer is not properly set when the database is different than the defaults

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11248?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11248: --------------------------------- Fix Version/s: 15.0.0.Final > EJB Timer is not properly set when the database is different than the defaults > ------------------------------------------------------------------------------ > > Key: WFLY-11248 > URL: https://issues.jboss.org/browse/WFLY-11248 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 14.0.0.Final > Reporter: Filippe Spolti > Assignee: Filippe Spolti > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > When using EJB timers the tables will be created during startup based on the database type. > If we set the *database* different than the default names, i.e. mariadb, mysql, it will fail: > timer-store example: > {code:xml} > <timer-service thread-pool-name="default" default-data-store="ejb_timer-EJB_TIMER_ds"> > <data-stores> > <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/> > <database-data-store name="ejb_timer-EJB_TIMER_ds" datasource-jndi-name="java:jboss/datasources/jbpmDS_EJBTimer" database="mysql57" partition="ejb_timer-EJB_TIMER_part" refresh-interval="30000"/> > </data-stores> > </timer-service> > {code} > Issue: > {code:java} > 2018-10-25 13:06:57,541 DEBUG [org.jboss.as.ejb3.timer] (MSC service thread 1-5) Database dialect 'mysql57' read from configuration > ... > 2018-10-25 13:06:58,056 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBossWS 5.2.3.Final (Apache CXF 3.2.5.jbossorg-1) > 2018-10-25 13:06:58,222 ERROR [org.jboss.as.ejb3.timer] (MSC service thread 1-5) WFLYEJB0163: Cannot create table for timer persistence: java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'PRIMARY KEY NOT NULL, TIMED_OBJECT_ID VARCHAR NOT NULL, INITIAL_DATE TIMESTAMP, ' at line 1 > at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:120) > at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97) > at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122) > at com.mysql.cj.jdbc.StatementImpl.executeUpdateInternal(StatementImpl.java:1354) > at com.mysql.cj.jdbc.StatementImpl.executeLargeUpdate(StatementImpl.java:2127) > at com.mysql.cj.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1264) > at com.mysql.cj.jdbc.StatementWrapper.executeUpdate(StatementWrapper.java:628) > at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:430) > at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.checkDatabase(DatabaseTimerPersistence.java:292) > at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.start(DatabaseTimerPersistence.java:166) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > {code} > This issue was spotted on OpenShift environment, the behavior there is to use as the database type on the datastore the same value than the datasource driver name, in this specific case, we we're trying a custom mysql jdbc driver version and named it to mysql57. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11145) multicastPrefix and anycastPrefix cannot be set

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11145?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11145: --------------------------------- Fix Version/s: 15.0.0.Final > multicastPrefix and anycastPrefix cannot be set > ----------------------------------------------- > > Key: WFLY-11145 > URL: https://issues.jboss.org/browse/WFLY-11145 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 14.0.0.Final > Reporter: Miroslav Novak > Assignee: ehsavoie Hugonnet > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > It's not possible to configure acceptor with {{multicastPrefix=jms.topic.}} and {{anycastPrefix=jms.queue."}}. > Problem is that those 2 parameters must be set to {{extraProps}} variable in TransportConfiguration: > https://github.com/apache/activemq-artemis/blob/a6b0b7e44291a76d6732c20b9... > however in messaging integration we don't call TransportConfiguration constructor with extreProps map: > https://github.com/wildfly/wildfly/blob/47b1db08fadb745706df7ba411db4f725... > Ideally this CLI command should configure acceptor with anycast/multicast prefixes: > {code} > /subsystem=messaging-activemq/server=default/acceptor=acceptor:add(socket-binding=http,factory-class=org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory,params={protocols="CORE",multicastPrefix="jms.topic",anycastPrefix="jms.queue"}) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11302) Update root README with getting started instructions for CD releases

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11302?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11302: --------------------------------- Fix Version/s: 15.0.0.Final > Update root README with getting started instructions for CD releases > -------------------------------------------------------------------- > > Key: WFLY-11302 > URL: https://issues.jboss.org/browse/WFLY-11302 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Reporter: Eduardo Martins > Assignee: Sande Gilda > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > The root README file only contains instructions only for regular project and product releases. It was not updated to include the correct instructions for the CD releases. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11250) Add support for registering a single JVM / Server wide default SSLContext

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11250?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11250: --------------------------------- Fix Version/s: 15.0.0.Final > Add support for registering a single JVM / Server wide default SSLContext > ------------------------------------------------------------------------- > > Key: WFLY-11250 > URL: https://issues.jboss.org/browse/WFLY-11250 > Project: WildFly > Issue Type: Feature Request > Components: Documentation, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > By registering a global SSLContext libraries used within the application server can make use of a managed SSLContext instead of relying on one automatically being created through the standard system properties. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11290) Look up of RemoteConnectionFactory with discovery-group is null

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11290?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11290: --------------------------------- Fix Version/s: 15.0.0.Final > Look up of RemoteConnectionFactory with discovery-group is null > --------------------------------------------------------------- > > Key: WFLY-11290 > URL: https://issues.jboss.org/browse/WFLY-11290 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 14.0.0.Final > Reporter: Miroslav Novak > Assignee: ehsavoie Hugonnet > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > If RemoteConnectionFactory is defined with discovery-group like (note that it's defined directly in messaging subsystem, not in <server>...</server>): > {code} > <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0"> > <discovery-group name="dg-group1" jgroups-channel="ee" jgroups-cluster="artemis-cluster" initial-wait-timeout="30000"/> > <connection-factory name="RemoteConnectionFactory" discovery-group="dg-group1" entries="java:jboss/exported/jms/RemoteConnectionFactory java:/jms/RemoteConnectionFactory"/> > </subsystem> > {code} > then it registers to JNDI "java:/jms/RemoteConnectionFactory" but with {{null}}. See JNDI view: > {code} > [standalone@localhost:9990 subsystem=naming] /subsystem=naming/:jndi-view > ... > "jms" => { > "class-name" => "javax.naming.Context", > "children" => { > "RemoteConnectionFactory" => { > "class-name" => "java.lang.Object", > "value" => "null" > }, > {code} > Result: > If EE deployment looks up or injects such CF then it fails on NullPointerException. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11179) Messaging http-acceptor should expose a capability and use it to control dependencies

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11179?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11179: --------------------------------- Fix Version/s: 15.0.0.Final > Messaging http-acceptor should expose a capability and use it to control dependencies > ------------------------------------------------------------------------------------- > > Key: WFLY-11179 > URL: https://issues.jboss.org/browse/WFLY-11179 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > An HTTPAcceptor brings some config and classloading deps that can probably be better controlled if a capability were used. > 1) Once WFCORE-4166 is done a capability requirement can be used for the required HttpListenerRegistryService, which will help ensure config consistency by making the config links clear. > 2) If there are any module dependencies the messaging subsystem module has that are only needed to support an HTTPAcceptor, then those can be made optional, and then the RuntimeCapability.Builder.addAdditionalRequiredPackages method can be used to record the requirement for those optional packages if the new capability is present. (Actually, at a glance it looks like the relevant module deps are already optional, so this bit is about telling Galleon when they are required.) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11181) XAResourceRecoveryServiceConfigurator adds a TX service dependency for non-transactional caches

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11181?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11181: --------------------------------- Fix Version/s: 15.0.0.Final > XAResourceRecoveryServiceConfigurator adds a TX service dependency for non-transactional caches > ----------------------------------------------------------------------------------------------- > > Key: WFLY-11181 > URL: https://issues.jboss.org/browse/WFLY-11181 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > I _think_ this is wrong... > XAResourceRecoveryServiceConfigurator is installed for all caches, not just ones with the ones with the component=transaction child resource. That's basically ok because its accept and get methods only do things if this.cache.get().getCacheConfiguration().transaction().recovery().enabled(). But, the problem is the service dependency on the XAResourceRecoveryRegistry service the transaction subsystem provides is always added, so even if is wouldn't be used the dependency is added. > I think WFLY-11167 will make it possible to correct this by 1) doing capability checking before adding the service dependency and 2) adding a capability requirement in TransactionResourceDefinition. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11177) Add an initial private capability for the JPA subsystem

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11177?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11177: --------------------------------- Fix Version/s: 15.0.0.Final > Add an initial private capability for the JPA subsystem > ------------------------------------------------------- > > Key: WFLY-11177 > URL: https://issues.jboss.org/browse/WFLY-11177 > Project: WildFly > Issue Type: Sub-task > Components: JPA / Hibernate > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > At some point we want a public capability for JPA, so it can expose a formal contract to other subsystem (e.g. weld.) But sorting out what that capability exposes doesn't need to block adding a private capability first. Having the private capability will allow the JPA subsystem to properly expose the requirements it has on capabilities exposed by other subsystems. And that will allow Galleon to properly understand those relationships when it generates configurations as part of server configuration. > So this subtask is to add such a private capability, with the remaining work of sorting out what public contract it will provide leftover as part of the parent issue. > It's not a problem to take a private capability and in the future make it public. And it's not a problem to change what a private capability exposes, i.e. in preparation for making it public. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11167) Create capability for XAResourceRecoveryRegistry

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11167?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-11167: --------------------------------- Fix Version/s: 15.0.0.Final > Create capability for XAResourceRecoveryRegistry > ------------------------------------------------ > > Key: WFLY-11167 > URL: https://issues.jboss.org/browse/WFLY-11167 > Project: WildFly > Issue Type: Sub-task > Components: Management, Transactions > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > See https://issues.jboss.org/browse/WFLY-9587?focusedCommentId=13647549&page=... in the parent issue. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 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 December 2018