[JBoss JIRA] (WFLY-5913) Add ability to specify external context on JNDI lookup binding
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-5913:
--------------------------------------------------
Summary: Add ability to specify external context on JNDI lookup binding
Key: WFLY-5913
URL: https://issues.jboss.org/browse/WFLY-5913
Project: WildFly
Issue Type: Feature Request
Components: Naming
Affects Versions: 10.0.0.CR5
Reporter: Guillermo González de Agüero
The Naming subsystem allows to create alias to JNDI lookups on the local context, and also allows to bind an external context to an entry. However, it isn't possible to bind a lookup to an external context.
My personal use case is that I have an exported JMS Topic on a Remote WildFly. I'd like to be able to use it from my application like if it where local.
For now, I've created an Object Factory that lookups the external context and then lookups the topic.
An attribute indicating the context could be added. If none specified, local context should be used. Something like this:
{code:xml}
<bindings>
<external-context name="java:/global/mqserver" module="org.jboss.as.naming" class="javax.naming.InitialContext" cache="true">
<environment>
<property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
<property name="java.naming.provider.url" value="http-remoting://localhost:8290"/>
<property name="java.naming.security.principal" value="remote"/>
<property name="java.naming.security.credentials" value="remote"/>
</environment>
</external-context>
<lookup name="java:/jms/topic/ImportedTopic" lookup="java:/jms/topic/MyTopic" externalContext="java:/global/mqserver"/>
</bindings>
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-4116) WAR deployment fails on missing security domain dependency
by John John (JIRA)
[ https://issues.jboss.org/browse/WFLY-4116?page=com.atlassian.jira.plugin.... ]
John John commented on WFLY-4116:
---------------------------------
Is this pasted anywhere on upgrading from 8.1 to 8.2 that the security-domain has changed in how it's defined in the jboss-web?
I too had 8.1 configs which had full path, but as you mentioned 8.2 seems to have shortened it.
Regards
John
> WAR deployment fails on missing security domain dependency
> ----------------------------------------------------------
>
> Key: WFLY-4116
> URL: https://issues.jboss.org/browse/WFLY-4116
> Project: WildFly
> Issue Type: Feature Request
> Components: Security, Web (JBoss Web), Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Standalone form-based authentication WAR
> Reporter: Lars Hellgren
> Assignee: Darran Lofthouse
> Fix For: 8.2.0.Final
>
>
> Moving WARs using form based authentication from WildFly 8.1 Final to 8.2 Final fails due to a missing security domain dependency.
> *Log*
> {noformat}
> service jboss.security.security-domain.java:/jaas/haa-portal (missing) dependents:
> [service jboss.deployment.unit."haa-security-manager.war".component.SecurityManagerRepositorySessionBean.CREATE,
> service jboss.deployment.unit."haa-security-manager.war".component.UserPrefsRepository.CREATE]
> {noformat}
> *jboss-web.xml*
> {code:xml}
> <jboss-web>
> <security-domain>java:/jaas/haa-portal</security-domain>
> </jboss-web>
> {code}
> *standalone.xml*
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
> <security-domain name="haa-portal">
> <authentication>
> <login-module code="Database" flag="required">
> ...
> </login-module>
> </authentication>
> </security-domain>
> </security-domains>
> </subsystem>
> {code}
> The datasource is deployed and connected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1982:
--------------------------------
Even better: if we keep requests in an array, we don't need to generate request-ids, e.g.:
{noformat}
offset=100 | R100 | R101 | R102 | R103 |
{noformat}
The next request would be R104, then R105 etc. The index into the current array plus the offset (which is adjusted on a compaction) give us a unique and monotonically increasing request-id.
Similar to {{Table}}, the array can grow, but it also can be compacted, e.g. by shifting elements in the array to the left (to index 0)...
> RequestCorrelator: use IntHashMap / LongHashmap for request correlation
> -----------------------------------------------------------------------
>
> Key: JGRP-1982
> URL: https://issues.jboss.org/browse/JGRP-1982
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (JGRP-1982) RequestCorrelator: use IntHashMap / LongHashmap for request correlation
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1982?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1982 at 12/25/15 10:10 AM:
-----------------------------------------------------------
Even better: if we keep requests in an array, we don't need to maintain {{REQUEST_ID}} (in {{Request}}), e.g.:
{noformat}
offset=100 | R100 | R101 | R102 | R103 |
{noformat}
The next request would be R104, then R105 etc. The index into the current array plus the offset (which is adjusted on a compaction) give us a unique and monotonically increasing request-id.
Similar to {{Table}}, the array can grow, but it also can be compacted, e.g. by shifting elements in the array to the left (to index 0)...
was (Author: belaban):
Even better: if we keep requests in an array, we don't need to generate request-ids, e.g.:
{noformat}
offset=100 | R100 | R101 | R102 | R103 |
{noformat}
The next request would be R104, then R105 etc. The index into the current array plus the offset (which is adjusted on a compaction) give us a unique and monotonically increasing request-id.
Similar to {{Table}}, the array can grow, but it also can be compacted, e.g. by shifting elements in the array to the left (to index 0)...
> RequestCorrelator: use IntHashMap / LongHashmap for request correlation
> -----------------------------------------------------------------------
>
> Key: JGRP-1982
> URL: https://issues.jboss.org/browse/JGRP-1982
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
>
> In RequestCorrelator (and possibly other classes), use an IntHashMap or LongHashmap for the request table. Goal: use less space when we have a lot of requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-5912) "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers a "phantom" DS
by Danilo Cominotti Marques (JIRA)
[ https://issues.jboss.org/browse/WFLY-5912?page=com.atlassian.jira.plugin.... ]
Danilo Cominotti Marques edited comment on WFLY-5912 at 12/24/15 8:11 PM:
--------------------------------------------------------------------------
Added a screenshot taken after clicking on "Test connection"
was (Author: dcominottim):
Screenshot taken after clicking on "Test connection"
> "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers a "phantom" DS
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5912
> URL: https://issues.jboss.org/browse/WFLY-5912
> Project: WildFly
> Issue Type: Bug
> Components: Server, Web Console
> Affects Versions: 10.0.0.CR5
> Reporter: Danilo Cominotti Marques
> Assignee: Jason Greene
> Attachments: WebConsole.jpg
>
>
> After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
> {noformat}
> 22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "CominottiDS")
> ]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-5912) "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers a "phantom" DS
by Danilo Cominotti Marques (JIRA)
[ https://issues.jboss.org/browse/WFLY-5912?page=com.atlassian.jira.plugin.... ]
Danilo Cominotti Marques updated WFLY-5912:
-------------------------------------------
Description:
After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
{noformat}
22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "CominottiDS")
]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
was:
After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "CominottiDS")
]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
> "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers a "phantom" DS
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5912
> URL: https://issues.jboss.org/browse/WFLY-5912
> Project: WildFly
> Issue Type: Bug
> Components: Server, Web Console
> Affects Versions: 10.0.0.CR5
> Reporter: Danilo Cominotti Marques
> Assignee: Jason Greene
> Attachments: WebConsole.jpg
>
>
> After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
> {noformat}
> 22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "CominottiDS")
> ]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-5912) "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers a "phantom" DS
by Danilo Cominotti Marques (JIRA)
[ https://issues.jboss.org/browse/WFLY-5912?page=com.atlassian.jira.plugin.... ]
Danilo Cominotti Marques updated WFLY-5912:
-------------------------------------------
Summary: "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers a "phantom" DS (was: "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS)
> "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers a "phantom" DS
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5912
> URL: https://issues.jboss.org/browse/WFLY-5912
> Project: WildFly
> Issue Type: Bug
> Components: Server, Web Console
> Affects Versions: 10.0.0.CR5
> Reporter: Danilo Cominotti Marques
> Assignee: Jason Greene
> Attachments: WebConsole.jpg
>
>
> After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
> 22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "CominottiDS")
> ]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-5912) "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
by Danilo Cominotti Marques (JIRA)
[ https://issues.jboss.org/browse/WFLY-5912?page=com.atlassian.jira.plugin.... ]
Danilo Cominotti Marques updated WFLY-5912:
-------------------------------------------
Attachment: WebConsole.jpg
Screenshot taken after clicking on "Test connection"
> "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5912
> URL: https://issues.jboss.org/browse/WFLY-5912
> Project: WildFly
> Issue Type: Bug
> Components: Server, Web Console
> Affects Versions: 10.0.0.CR5
> Reporter: Danilo Cominotti Marques
> Assignee: Jason Greene
> Attachments: WebConsole.jpg
>
>
> After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
> 22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "CominottiDS")
> ]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (WFLY-5912) "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
by Danilo Cominotti Marques (JIRA)
Danilo Cominotti Marques created WFLY-5912:
----------------------------------------------
Summary: "Test Connection" feature from the Datasources configuration UI with a Postgres DS inadvertently registers the DS
Key: WFLY-5912
URL: https://issues.jboss.org/browse/WFLY-5912
Project: WildFly
Issue Type: Bug
Components: Server, Web Console
Affects Versions: 10.0.0.CR5
Reporter: Danilo Cominotti Marques
Assignee: Jason Greene
After adding the postgresql-9.4-1201.jdbc41 driver/module to WildFly and configuring a datasource in the web console, when I click on "Test connection" instead of finishing the configuration, a success message appears along with a "Reload server now" message because the datasource has inadvertently been registered already; and when the server is reloaded, I can't see the newly registered datasource in the web console. Below is the console log I get when I try to actually finalize the same datasource configuration after having but tested its connection and reloaded the server as per the web console messages:
{{22:41:08,708 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "CominottiDS")
]): org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.data-source.CominottiDS is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158)
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235)
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:768)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
at org.jboss.as.controller.OperationContextImpl$ContextServiceBuilder.install(OperationContextImpl.java:2129)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.firstRuntimeStep(AbstractDataSourceAdd.java:185)
at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceAdd.performRuntime(AbstractDataSourceAdd.java:106)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
at org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:212)
at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:95)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months