[JBoss JIRA] (WFLY-5914) JNDI view ClassNotFoundException with remote entry
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-5914?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero updated WFLY-5914:
-----------------------------------------------
Attachment: domain.zip
Whole domain folder
> JNDI view ClassNotFoundException with remote entry
> --------------------------------------------------
>
> Key: WFLY-5914
> URL: https://issues.jboss.org/browse/WFLY-5914
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Naming
> Affects Versions: 10.0.0.CR5
> Reporter: Guillermo González de Agüero
> Assignee: Jeff Mesnil
> Attachments: domain.xml, domain.zip
>
>
> 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, 3 months
[JBoss JIRA] (WFLY-4296) remove _ds.xml deployment support
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/WFLY-4296?page=com.atlassian.jira.plugin.... ]
arjan tijms commented on WFLY-4296:
-----------------------------------
{quote}I'd much prefer for this to be fixed so that deploying a -ds.xml file in the deployments folder does indeed deploy this as a new datasource, (I'm fine with this only working in standalone mode by the way).{quote}
You can basically still do that with the standard {{data-source}} element (or the annotation if you so prefer). Just deploy a war with only the data source definition (use {{java:global}}) independently from the application that uses that data source. This is largely like you'd do with the deployment of a {{-ds.xml}} file.
{quote}Multitennanted systems which rely on database partitioning (Different database per tennant), and thus require a specific datasource per tennant, decided at runtime, would not be possible if this feature is deprecated{quote}
Which feature of {{-ds.xml}} is that exactly? If you're missing specific features then it may be an idea to ask Red Hat to add those (via properties) to the standard {{data-source}} one. There are indeed a (large) number of pool settings that JBoss/WildFly doesn't wire from the properties. I studied the source and it looks relatively easy to do it, it's just that it isn't done.
Another avenue is asking for standardisation of features for Java EE 8's {{data-source}}. This would mean writing a mail to the Java EE mailing list at users(a)javaee-spec.java.net
> remove _ds.xml deployment support
> ---------------------------------
>
> Key: WFLY-4296
> URL: https://issues.jboss.org/browse/WFLY-4296
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Stefano Maestri
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5921) Locale cache set to simple cache automatically breaks map reduce
by Stian Thorgersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-5921?page=com.atlassian.jira.plugin.... ]
Stian Thorgersen closed WFLY-5921.
----------------------------------
Resolution: Rejected
We're going to detect version of Infinispan and use distributed streams for new version, while maintaining map-reduce for now.
BTW this is the second time we've run into issues with the Infinispan subsystem making changes to defaults, while not allowing actually changing the values. IMO it's not very nice to automatically convert a local-cache to a simple-cache and not even provide an option to disable it.
> Locale cache set to simple cache automatically breaks map reduce
> ----------------------------------------------------------------
>
> Key: WFLY-5921
> URL: https://issues.jboss.org/browse/WFLY-5921
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Stian Thorgersen
> Assignee: Paul Ferraro
> Priority: Critical
>
> We use the Infinispan subsystem to create/configure caches for Keycloak. In standalone mode Keycloak uses locale-caches, while in clustered mode we use a combination of invalidation caches and distributed caches. In both clustered and non-clustered mode we use map-reduce tasks to delete elements from the cache.
> This has worked just fine until the recent change in CR5 where locale-caches are now set to simple-caches (WFLY-5327). As the caches are now automatically set to simple-caches map-reduce is no longer available. There's also no way to prevent this.
> IMO the changes from WFLY-5327 should be reverted and instead a new simple-cache element should be added, or a simple-cache=true attribute added to the locale-cache element.
> As it stands this change prevents us from upgrading to CR5.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1012) kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1012?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1012:
-------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1293965|https://bugzilla.redhat.com/show_bug.cgi?id=1293965] from ASSIGNED to MODIFIED
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1012
> URL: https://issues.jboss.org/browse/DROOLS-1012
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
> Attachments: brms-fuse-integration-master.tgz
>
>
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry. This implies that when the KieContainer is created in a OSGi environment it is not able to get an instance of the MavenClassLoaderResolver and then cannot create a ClassLoader including all the transitive dependencies of the kjar to be compiled.
> The attached project reproduces this issue. In order to run it, it's enough to do a mvn clean install of the project and issue the following commands in fuse:
> features:addurl mvn:com.redhat/brms-fuse-integration-features/0.0.1-SNAPSHOT/xml/features
> features:install brms-integration-bundle
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1012) kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1012?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1012:
-------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1293455|https://bugzilla.redhat.com/show_bug.cgi?id=1293455] from ASSIGNED to MODIFIED
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1012
> URL: https://issues.jboss.org/browse/DROOLS-1012
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
> Attachments: brms-fuse-integration-master.tgz
>
>
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry. This implies that when the KieContainer is created in a OSGi environment it is not able to get an instance of the MavenClassLoaderResolver and then cannot create a ClassLoader including all the transitive dependencies of the kjar to be compiled.
> The attached project reproduces this issue. In order to run it, it's enough to do a mvn clean install of the project and issue the following commands in fuse:
> features:addurl mvn:com.redhat/brms-fuse-integration-features/0.0.1-SNAPSHOT/xml/features
> features:install brms-integration-bundle
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1260) Capability resolution complaints on admin-only slave HCs not connected to the master
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1260?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1260:
-------------------------------------
Description:
If you start a slave HC in admin-only with no master to connect to, boot is fine but then any modifications made to the config result in capability resolution ERROR messages in the host-controller.log
Starting a slave HC in admin-only with no master to connect to is meant to work, allowing you to use CLI to manipulate the slave's host config:
{code}
bin/domain.sh --host-config=host-slave.xml --admin-only -Djboss.domain.master.address=127.0.0.1
{code}
The boot is fine:
{code}
[Host Controller] 11:06:10,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final-SNAPSHOT (WildFly Core 2.0.5.Final) (Host Controller) started in 1152ms - Started 41 of 42 services (12 services are lazy, passive or on-demand)
{code}
However, subsequent changes made via management tools (e.g. CLI) succeed but result in ERROR logging by the HC:
{code}
[domain@127.0.0.1:9999 /] /host=localhost/system-property=foo:add(value=bar)
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
{code}
The HC's log:
{code}
[Host Controller] 11:07:37,744 ERROR [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0369: Required capabilities are not available:
[Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
[Host Controller] org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
{code}
The boot works without logging because of the enhancement Stuart added such that capability reference failures won't fail an admin-only boot, thus letting the user use admin-only to fix the config. But then with subsequent changes, the user gets ERRORs notifying them of the unfixed references.
But in this case, the references will never be available, so long as there is no connection to a master to provide the domain-wide config.
This is a general case that needs to be accounted for in the capability resolution logic.
was:
If you start a slave HC in admin-only with no master to connect to, boot is fine but then any modifications made to the config result in capabiloty resolution ERROR messages in the host-controller.log
Starting a slave HC in admin-only with no master to connect to is meant to work, allowing you to use CLI to manipulate the slave's host config:
{code}
bin/domain.sh --host-config=host-slave.xml --admin-only -Djboss.domain.master.address=127.0.0.1
{code}
The boot is fine:
{code}
[Host Controller] 11:06:10,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final-SNAPSHOT (WildFly Core 2.0.5.Final) (Host Controller) started in 1152ms - Started 41 of 42 services (12 services are lazy, passive or on-demand)
{code}
However, subsequent changes made via management tools (e.g. CLI) succeed result in ERROR logging by the HC:
{code}
[domain@127.0.0.1:9999 /] /host=localhost/system-property=foo:add(value=bar)
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
{code}
The HC's log:
{code}
[Host Controller] 11:07:37,744 ERROR [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0369: Required capabilities are not available:
[Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
[Host Controller] org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
{code}
The boot works without logging because of the enhancement Stuart added such that capability references failures won't fail an admin-only boot, thus letting the user use admin-only to fix the changes. But then with subsequent changes, the user gets ERRORs notifying them of the unfixed references.
But in this case, the references will never be available, so long as there is no connection to a master to provide the domain-wide config.
This is a general case that needs to be accounted for in the capability resolution logic.
> Capability resolution complaints on admin-only slave HCs not connected to the master
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1260
> URL: https://issues.jboss.org/browse/WFCORE-1260
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.5.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> If you start a slave HC in admin-only with no master to connect to, boot is fine but then any modifications made to the config result in capability resolution ERROR messages in the host-controller.log
> Starting a slave HC in admin-only with no master to connect to is meant to work, allowing you to use CLI to manipulate the slave's host config:
> {code}
> bin/domain.sh --host-config=host-slave.xml --admin-only -Djboss.domain.master.address=127.0.0.1
> {code}
> The boot is fine:
> {code}
> [Host Controller] 11:06:10,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final-SNAPSHOT (WildFly Core 2.0.5.Final) (Host Controller) started in 1152ms - Started 41 of 42 services (12 services are lazy, passive or on-demand)
> {code}
> However, subsequent changes made via management tools (e.g. CLI) succeed but result in ERROR logging by the HC:
> {code}
> [domain@127.0.0.1:9999 /] /host=localhost/system-property=foo:add(value=bar)
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> {code}
> The HC's log:
> {code}
> [Host Controller] 11:07:37,744 ERROR [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0369: Required capabilities are not available:
> [Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> [Host Controller] org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> {code}
> The boot works without logging because of the enhancement Stuart added such that capability reference failures won't fail an admin-only boot, thus letting the user use admin-only to fix the config. But then with subsequent changes, the user gets ERRORs notifying them of the unfixed references.
> But in this case, the references will never be available, so long as there is no connection to a master to provide the domain-wide config.
> This is a general case that needs to be accounted for in the capability resolution logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1261) Changing the max-history attribute value for configuration-changes fails
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-1261:
-----------------------------------------
Summary: Changing the max-history attribute value for configuration-changes fails
Key: WFCORE-1261
URL: https://issues.jboss.org/browse/WFCORE-1261
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.5.Final
Reporter: ehsavoie Hugonnet
Assignee: Brian Stansberry
[standalone@localhost:9990 /] /core-service=management/service=configuration-changes:write-attribute(name=max-history,value=20)
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0188: Stage MODEL is already complete",
"rolled-back" => true
}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1261) Changing the max-history attribute value for configuration-changes fails
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1261?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet reassigned WFCORE-1261:
-----------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
> Changing the max-history attribute value for configuration-changes fails
> ------------------------------------------------------------------------
>
> Key: WFCORE-1261
> URL: https://issues.jboss.org/browse/WFCORE-1261
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.5.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> [standalone@localhost:9990 /] /core-service=management/service=configuration-changes:write-attribute(name=max-history,value=20)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0188: Stage MODEL is already complete",
> "rolled-back" => true
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1260) Capability resolution complaints on admin-only slave HCs not connected to the master
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1260:
----------------------------------------
Summary: Capability resolution complaints on admin-only slave HCs not connected to the master
Key: WFCORE-1260
URL: https://issues.jboss.org/browse/WFCORE-1260
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.5.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
If you start a slave HC in admin-only with no master to connect to, boot is fine but then any modifications made to the config result in capabiloty resolution ERROR messages in the host-controller.log
Starting a slave HC in admin-only with no master to connect to is meant to work, allowing you to use CLI to manipulate the slave's host config:
{code}
bin/domain.sh --host-config=host-slave.xml --admin-only -Djboss.domain.master.address=127.0.0.1
{code}
The boot is fine:
{code}
[Host Controller] 11:06:10,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final-SNAPSHOT (WildFly Core 2.0.5.Final) (Host Controller) started in 1152ms - Started 41 of 42 services (12 services are lazy, passive or on-demand)
{code}
However, subsequent changes made via management tools (e.g. CLI) succeed result in ERROR logging by the HC:
{code}
[domain@127.0.0.1:9999 /] /host=localhost/system-property=foo:add(value=bar)
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
{code}
The HC's log:
{code}
[Host Controller] 11:07:37,744 ERROR [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0369: Required capabilities are not available:
[Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
[Host Controller] org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
{code}
The boot works without logging because of the enhancement Stuart added such that capability references failures won't fail an admin-only boot, thus letting the user use admin-only to fix the changes. But then with subsequent changes, the user gets ERRORs notifying them of the unfixed references.
But in this case, the references will never be available, so long as there is no connection to a master to provide the domain-wide config.
This is a general case that needs to be accounted for in the capability resolution logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5914) JNDI view ClassNotFoundException with remote entry
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5914?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-5914:
-----------------------------------
I could not reproduce your issue on the latest WildFly checkout using your domain.xml. On both servers, the :jodi-view operation succeeds and display the JMS topic as expected:
{noformat}
"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=8230&host=localhost], discoveryGroupConfiguration=null], clientID=null, consumerWindowSize = 1048576, dupsOKBatchSize=1048576, transactionBatchSize=1048576, readOnly=false]"
},
"topic" => {
"class-name" => "javax.naming.Context",
"children" => {"prueba" => {
"class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQTopic",
"value" => "ActiveMQTopic[PruebaTopic]"
}}
},
"queue" => {
"class-name" => "javax.naming.Context",
"children" => {"prueba" => {
"class-name" => "org.apache.activemq.artemis.jms.client.ActiveMQQueue",
"value" => "ActiveMQQueue[PruebaQueue]"
}}
}
}
}},
{noformat}
> JNDI view ClassNotFoundException with remote entry
> --------------------------------------------------
>
> Key: WFLY-5914
> URL: https://issues.jboss.org/browse/WFLY-5914
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Naming
> Affects Versions: 10.0.0.CR5
> Reporter: Guillermo González de Agüero
> Assignee: Jeff Mesnil
> 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, 3 months