[JBoss JIRA] (WFLY-5914) JNDI view ClassNotFoundException with remote entry
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-5914:
--------------------------------------------------
Summary: JNDI view ClassNotFoundException with remote entry
Key: WFLY-5914
URL: https://issues.jboss.org/browse/WFLY-5914
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.CR5
Reporter: Guillermo González de Agüero
Assignee: Jason Greene
Attachments: domain.xml
When a binding to a remote Artemis Topic/ConnectionFactory is created, JNDI view fails with a ClassNotFoundException. Both servers are running the "full" profile.
I attach my domain.xml for reference porpuses. No application needs to be deployed.
Full operation result:
[domain@localhost:9990 /] /host=master/server=app-ins01/subsystem=naming:jndi-view()
{
"outcome" => "failed",
"result" => {"java: contexts" => {
"java:" => {
"ConnectionFactory" => {
"class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory",
"value" => "ActiveMQConnectionFactory [serverLocator=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=in-vm, factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0], discoveryGroupConfiguration=null], clientID=null, consumerWindowSize = 1048576, dupsOKBatchSize=1048576, transactionBatchSize=1048576, readOnly=false]"
},
"JmsXA" => {
"class-name" => "java.lang.Object",
"value" => "?"
},
"TransactionManager" => {
"class-name" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate",
"value" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@27b3c7"
},
"jms" => {
"class-name" => "javax.naming.Context",
"children" => {"queue" => {
"class-name" => "javax.naming.Context",
"children" => {
"DLQ" => {
"class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQQueue",
"value" => "ActiveMQQueue[DLQ]"
},
"ExpiryQueue" => {
"class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQQueue",
"value" => "ActiveMQQueue[ExpiryQueue]"
}
}
}}
},
"jboss" => {
"class-name" => "javax.naming.Context",
"value" => "org.jboss.as.naming.WritableServiceBasedNamingStore@d2c52f"
},
"global" => {
"class-name" => "javax.naming.Context",
"value" => "org.jboss.as.naming.WritableServiceBasedNamingStore@932e80"
},
"ejb" => {
"class-name" => "javax.naming.Context",
"children" => {"mgmt" => {
"class-name" => "javax.naming.Context",
"children" => {"MEJB" => {
"class-name" => "javax.management.j2ee.ManagementHome",
"value" => "Proxy for remote EJB EJBHomeLocator for \"jsr-77/jsr-77/EJB\", view is interface javax.management.j2ee.ManagementHome, affinity is None"
}}
}}
}
},
"java:jboss" => {
"ORB" => {
"class-name" => "com.sun.corba.se.impl.orb.ORBImpl",
"value" => "com.sun.corba.se.impl.orb.ORBImpl@1306d15"
},
"TransactionManager" => {
"class-name" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate",
"value" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@27b3c7"
},
"TransactionSynchronizationRegistry" => {
"class-name" => "org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper",
"value" => "org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@206b4c"
},
"UserTransaction" => {
"class-name" => "javax.transaction.UserTransaction",
"value" => "UserTransaction"
},
"corbanaming" => {
"class-name" => "org.omg.CosNaming._NamingContextExtStub",
"value" => "IOR:000000000000002b49444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e300000000000010000000000000110000102000000000a3132372e302e302e31000e3600000039afabcb00000000220000000100000001000000000000000200000008526f6f74504f4100000000074e616d696e67000000000004726f6f741400000000000005000000010000002000000000000100010000000205010001000100200001010900000001000101000000002600000002000200000000000300000014000000000000000a3132372e302e302e31000e3700000014000000080000001a00000e370000002100000050000000000000000100000000000000220000000000400000000000080606678102010101000000170401000806066781020101010000000744656661756c740000000000000000000000000000000000"
},
"irpoa" => {
"class-name" => "com.sun.corba.se.impl.oa.poa.POAImpl",
"value" => "POA[ObjectAdapterID[RootPOA/IRPOA], uniquePOAId=2, state=RUN, invocationCount=0]"
},
"jaas" => {
"class-name" => "com.sun.proxy.$Proxy58",
"value" => "java:jboss/jaas/ Context proxy"
},
"poa" => {
"class-name" => "com.sun.corba.se.impl.oa.poa.POAImpl",
"value" => "POA[ObjectAdapterID[RootPOA], uniquePOAId=0, state=RUN, invocationCount=0]"
},
"ee" => {
"class-name" => "javax.naming.Context",
"children" => {"concurrency" => {
"class-name" => "javax.naming.Context",
"children" => {
"scheduler" => {
"class-name" => "javax.naming.Context",
"children" => {"default" => {
"class-name" => "java.lang.Object",
"value" => "?"
}}
},
"factory" => {
"class-name" => "javax.naming.Context",
"children" => {"default" => {
"class-name" => "java.lang.Object",
"value" => "?"
}}
},
"executor" => {
"class-name" => "javax.naming.Context",
"children" => {"default" => {
"class-name" => "java.lang.Object",
"value" => "?"
}}
},
"context" => {
"class-name" => "javax.naming.Context",
"children" => {"default" => {
"class-name" => "java.lang.Object",
"value" => "?"
}}
}
}
}}
},
"infinispan" => {
"class-name" => "javax.naming.Context",
"children" => {"container" => {
"class-name" => "javax.naming.Context",
"children" => {
"ejb" => {
"class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
"value" => "ejb"
},
"hibernate" => {
"class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
"value" => "hibernate"
},
"server" => {
"class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
"value" => "server"
},
"web" => {
"class-name" => "org.jboss.as.clustering.infinispan.DefaultCacheContainer",
"value" => "web"
}
}
}}
},
"datasources" => {
"class-name" => "javax.naming.Context",
"children" => {"ExampleDS" => {
"class-name" => "org.jboss.as.connector.subsystems.datasources.WildFlyDataSource",
"value" => "org.jboss.as.connector.subsystems.datasources.WildFlyDataSource@c79ae8"
}}
},
"mail" => {
"class-name" => "javax.naming.Context",
"children" => {"Default" => {
"class-name" => "javax.mail.Session",
"value" => "javax.mail.Session@1e9f277"
}}
},
"clustering" => {
"class-name" => "javax.naming.Context",
"children" => {"registry" => {
"class-name" => "javax.naming.Context",
"children" => {"ejb" => {
"class-name" => "javax.naming.Context",
"children" => {"client-mappings" => {
"class-name" => "org.wildfly.clustering.server.registry.CacheRegistryFactory",
"value" => "org.wildfly.clustering.server.registry.CacheRegistryFactory@12ac291"
}}
}}
}}
}
},
"java:jboss/exported" => {"jms" => {
"class-name" => "javax.naming.Context",
"children" => {"RemoteConnectionFactory" => {
"class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory",
"value" => "ActiveMQConnectionFactory [serverLocator=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-apache-activemq-artemis-core-remoting-impl-netty-NettyConnectorFactory) ?httpUpgradeEnabled=true&httpPpgradeEndpoint=http-acceptor&port=8190&host=127-0-0-1], discoveryGroupConfiguration=null], clientID=null, consumerWindowSize = 1048576, dupsOKBatchSize=1048576, transactionBatchSize=1048576, readOnly=false]"
}}
}},
"java:global" => undefined
}},
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: org.jboss.naming.remote.protocol.NamingIOException: Failed to lookup [Root exception is java.io.IOException: java.lang.ClassNotFoundException: org.apache.activemq.artemis.jms.client.ActiveMQJMSConnectionFactory from [Module \"org.jboss.as.naming:main\" from local module loader @130015a (finder: local module finder @9f0666 (roots: c:\\wildfly-10.0.0.CR5\\modules,c:\\wildfly-10.0.0.CR5\\modules\\system\\layers\\base))]]",
"rolled-back" => true
}
Injection of the resources via @Resource in an application works as expected. I found this same problem where manually doing the remote lookup from application code, which I resolved adding a dependency to Artemis module in META-INF.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 4 months
[JBoss JIRA] (WFLY-5913) Add ability to specify external context on JNDI lookup binding
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-5913?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero resolved WFLY-5913.
------------------------------------------------
Resolution: Done
My fault. It's already possible to do a remote lookup by appending the path to the lookup of the remote context.
For reference porpuses, my configuration currently is:
{code:xml}
<subsystem xmlns="urn:jboss:domain:naming:2.0">
<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:global/ExportedTopic" lookup="java:/global/mqserver/jms/topic/prueba"/>
<lookup name="java:global/ExportedFactory" lookup="java:/global/mqserver/jms/RemoteConnectionFactory"/>
</bindings>
<remote-naming/>
</subsystem>
{code}
Maybe an explanation could be added to the docs.
> 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)
10 years, 4 months
[JBoss JIRA] (WFLY-5913) Add ability to specify external context on JNDI lookup binding
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-5913?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero updated WFLY-5913:
-----------------------------------------------
Description:
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}
was:
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}
> 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)
10 years, 4 months
[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)
10 years, 4 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)
10 years, 4 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)
10 years, 4 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)
10 years, 4 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)
10 years, 4 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)
10 years, 4 months