[JBoss JIRA] (WFLY-4579) BeanManager method getBeans() is not available during application initialization
by Thomas Meyer (JIRA)
[ https://issues.jboss.org/browse/WFLY-4579?page=com.atlassian.jira.plugin.... ]
Thomas Meyer commented on WFLY-4579:
------------------------------------
Original stack trace leading to the IllegalStateException:
Thread [MSC service thread 1-4] (Suspended (exception IllegalStateException))
owns: JavaFlowLoaderHelper (id=185)
BeanManagerProxy.checkContainerState(String, ContainerState) line: 246
BeanManagerProxy.checkContainerState(String) line: 251
BeanManagerProxy.getBeans(Type, Annotation...) line: 100
JavaFlowLoaderHelper.loadFlows(FacesContext, FlowHandler) line: 66
ApplicationAssociate$PostConstructApplicationListener.processEvent(SystemEvent) line: 298
PostConstructApplicationEvent(SystemEvent).processListener(FacesListener) line: 108
ApplicationImpl.processListeners(Collection<SystemEventListener>, SystemEvent, Object, EventInfo) line: 2190
ApplicationImpl.invokeListenersFor(Class<SystemEvent>, SystemEvent, Object, Class<?>, boolean) line: 2163
ApplicationImpl.publishEvent(FacesContext, Class<SystemEvent>, Class<?>, Object) line: 296
WeldApplication(ForwardingApplication).publishEvent(FacesContext, Class<SystemEvent>, Class<?>, Object) line: 294
ConfigManager.publishPostConfigEvent() line: 692
ConfigureListener.contextInitialized(ServletContextEvent) line: 260
ApplicationListeners.contextInitialized() line: 173
DeploymentManagerImpl.deploy() line: 193
UndertowDeploymentService.startContext() line: 87
UndertowDeploymentService.start(StartContext) line: 72
ServiceControllerImpl$StartTask.startService(Service<? extends S>, StartContext) line: 1948
ServiceControllerImpl$StartTask.run() line: 1881
ServiceContainerImpl$ContainerExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: 1142
ThreadPoolExecutor$Worker.run() line: 617
ServiceContainerImpl$ServiceThread(Thread).run() line: 745
This seems to happen because the EAR contains one WebApp. In this one WebApp we have an JSF servlet and an JAX-RS servlet. We did add an wait listener now in the web.xml file:
<listener>
<listener-class>listener.WaitListener</listener-class>
</listener>
Which basically does:
public void contextInitialized(ServletContextEvent sce) {
ServletContext context = sce.getServletContext();
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
With this listener installed, the EAR can be deployed sucessfully on WildFly.
May be related to https://issues.jboss.org/browse/WFLY-3259 and https://issues.jboss.org/browse/WFLY-3207
> BeanManager method getBeans() is not available during application initialization
> --------------------------------------------------------------------------------
>
> Key: WFLY-4579
> URL: https://issues.jboss.org/browse/WFLY-4579
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Environment: Windows 7
> Reporter: Thomas Meyer
> Assignee: Stuart Douglas
>
> Deployment of an EAR fails because of this exception:
> 09:34:30,854 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment Project-ejb.jar
> 09:34:30,862 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named ModelContext in deployment unit subdeployment "Project-ejb.jar" of deployment "Project-ear-0.1.0-SNAPSHOT.ear" are as follows:
> java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/ModelContext!simulator.ModelContext
> java:app/Project-ejb/ModelContext!simulator.ModelContext
> java:module/ModelContext!simulator.ModelContext
> java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/ModelContext
> java:app/Project-ejb/ModelContext
> java:module/ModelContext
> 09:34:30,863 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named AccountsBean in deployment unit subdeployment "Project-ejb.jar" of deployment "Project-ear-0.1.0-SNAPSHOT.ear" are as follows:
> java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/AccountsBean!simulator.AccountsBean
> java:app/Project-ejb/AccountsBean!simulator.AccountsBean
> java:module/AccountsBean!simulator.AccountsBean
> java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/AccountsBean
> java:app/Project-ejb/AccountsBean
> java:module/AccountsBean
> 09:34:30,864 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named ContactsBean in deployment unit subdeployment "Project-ejb.jar" of deployment "Project-ear-0.1.0-SNAPSHOT.ear" are as follows:
> java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/ContactsBean!simulator.ContactsBean
> java:app/Project-ejb/ContactsBean!simulator.ContactsBean
> java:module/ContactsBean!simulator.ContactsBean
> java:global/Project-ear-0.1.0-SNAPSHOT/Project-ejb/ContactsBean
> java:app/Project-ejb/ContactsBean
> java:module/ContactsBean
> 09:34:30,892 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment Project-webapp.war
> 09:34:30,954 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: Project-ear-0.1.0-SNAPSHOT.ear
> 09:34:31,016 INFO [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900: 2.2.6 (Final)
> 09:34:31,169 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016008: Starting weld service for deployment Project-ear-0.1.0-SNAPSHOT.ear
> 09:34:32,203 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Mojarra 2.2.8-jbossorg-1 20140822-1131 f³r Kontext '/v1' wird initialisiert.
> 09:34:33,738 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Critical error during deployment: : org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
> at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerState(BeanManagerProxy.java:246) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerState(BeanManagerProxy.java:251) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:100) [weld-core-impl-2.2.6.Final.jar:2014-10-03 10:05]
> at com.sun.faces.application.JavaFlowLoaderHelper.loadFlows(JavaFlowLoaderHelper.java:66) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.processEvent(ApplicationAssociate.java:298) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2190) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:296) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.2.0.Final.jar:8.2.0.Final]
> at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:692) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:260) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:193) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
> 09:34:33,938 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./v1: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./v1: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:222)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> ... 3 more
> Caused by: java.lang.RuntimeException: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:280)
> at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:193)
> ... 7 more
> Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
> at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerState(BeanManagerProxy.java:246)
> at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerState(BeanManagerProxy.java:251)
> at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:100)
> at com.sun.faces.application.JavaFlowLoaderHelper.loadFlows(JavaFlowLoaderHelper.java:66)
> at com.sun.faces.application.ApplicationAssociate$PostConstructApplicationListener.processEvent(ApplicationAssociate.java:298)
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108)
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2190)
> at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163)
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:296)
> at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294)
> at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:692)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:260)
> ... 9 more
> 09:34:34,099 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "Project-ear-0.1.0-SNAPSHOT.ear")]) - failure description: {"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./v1" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./v1: Failed to start service
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
> Caused by: java.lang.RuntimeException: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
> Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization"}}
> 09:34:34,188 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "Project-ear-0.1.0-SNAPSHOT.ear" (runtime-name : "Project-ear-0.1.0-SNAPSHOT.ear")
> 09:34:34,188 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
> JBAS014777: Services which failed to start:
> service jboss.undertow.deployment.default-server.default-host./v1: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./v1: Failed to start service
> The EAR contains:
> 1.) An EJB JAR
> 2.) An WepApp WAR
> The webapp uses JSF and JAX-RS.
> None of our code seesm to be involved.
> The EAR can succesfully deployet on an Weblogic AS.
> When I start the WildFly AS with --debug mode and halt at BeanManagerProxy.getBeans() and directly continue the thread exectuion. the deployment of the EAR file works correctly. Feels like some race condition..
> Any ideas how to fix this?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (JBJCA-1265) Cannot deploy "datasource.xml" file into embedded IronJacamar container
by Nickolay Laptev (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1265?page=com.atlassian.jira.plugin... ]
Nickolay Laptev commented on JBJCA-1265:
----------------------------------------
That's not a question.
And that's very sad you guys think it's a normal behaviour.
> Cannot deploy "datasource.xml" file into embedded IronJacamar container
> -----------------------------------------------------------------------
>
> Key: JBJCA-1265
> URL: https://issues.jboss.org/browse/JBJCA-1265
> Project: IronJacamar
> Issue Type: Bug
> Components: Embedded
> Affects Versions: 1.1.0.Beta5
> Environment: MacOS X
> Reporter: Nickolay Laptev
> Assignee: Jesper Pedersen
>
> I cannot deploy file with name "datasource.xml" into embedded container.
> Got the following in stack trace while loading JNDI component:
> Caused by: javax.naming.NameNotFoundException: PostgresDS not bound
> at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
> at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
> at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
> at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:155)
> at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:87)
> at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:152)
> at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:179)
> at org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:95)
> at org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:106)
> at org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObjectFactoryBean.java:231)
> at org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObjectFactoryBean.java:217)
> The fun this is that it's actual just for name "datasource.xml". If I change it to some other name the file will be deployed without any problems.
> Seems "datasource.xml" is hardcoded in some way in embedded container.
> Sample code:
> System.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
> System.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
> Embedded container; // initialized with Spring <bean id="container" class="org.jboss.jca.embedded.EmbeddedFactory" factory-method="create"/>
> container.startup();
> container.deploy("jdbc-xa.rar");
> container.deploy("datasource.xml");
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (JBJCA-1265) Cannot deploy "datasource.xml" file into embedded IronJacamar container
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1265?page=com.atlassian.jira.plugin... ]
Jesper Pedersen closed JBJCA-1265.
----------------------------------
Resolution: Rejected
Use the user forum for questions
> Cannot deploy "datasource.xml" file into embedded IronJacamar container
> -----------------------------------------------------------------------
>
> Key: JBJCA-1265
> URL: https://issues.jboss.org/browse/JBJCA-1265
> Project: IronJacamar
> Issue Type: Bug
> Components: Embedded
> Affects Versions: 1.1.0.Beta5
> Environment: MacOS X
> Reporter: Nickolay Laptev
> Assignee: Jesper Pedersen
>
> I cannot deploy file with name "datasource.xml" into embedded container.
> Got the following in stack trace while loading JNDI component:
> Caused by: javax.naming.NameNotFoundException: PostgresDS not bound
> at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
> at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
> at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
> at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
> at javax.naming.InitialContext.lookup(InitialContext.java:417)
> at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:155)
> at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:87)
> at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:152)
> at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:179)
> at org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:95)
> at org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:106)
> at org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObjectFactoryBean.java:231)
> at org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObjectFactoryBean.java:217)
> The fun this is that it's actual just for name "datasource.xml". If I change it to some other name the file will be deployed without any problems.
> Seems "datasource.xml" is hardcoded in some way in embedded container.
> Sample code:
> System.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
> System.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
> Embedded container; // initialized with Spring <bean id="container" class="org.jboss.jca.embedded.EmbeddedFactory" factory-method="create"/>
> container.startup();
> container.deploy("jdbc-xa.rar");
> container.deploy("datasource.xml");
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (JBJCA-1265) Cannot deploy "datasource.xml" file into embedded IronJacamar container
by Nickolay Laptev (JIRA)
Nickolay Laptev created JBJCA-1265:
--------------------------------------
Summary: Cannot deploy "datasource.xml" file into embedded IronJacamar container
Key: JBJCA-1265
URL: https://issues.jboss.org/browse/JBJCA-1265
Project: IronJacamar
Issue Type: Bug
Components: Embedded
Affects Versions: 1.1.0.Beta5
Environment: MacOS X
Reporter: Nickolay Laptev
Assignee: Jesper Pedersen
I cannot deploy file with name "datasource.xml" into embedded container.
Got the following in stack trace while loading JNDI component:
Caused by: javax.naming.NameNotFoundException: PostgresDS not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
at org.jnp.server.NamingServer.lookup(NamingServer.java:443)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:726)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:155)
at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:87)
at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:152)
at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:179)
at org.springframework.jndi.JndiLocatorSupport.lookup(JndiLocatorSupport.java:95)
at org.springframework.jndi.JndiObjectLocator.lookup(JndiObjectLocator.java:106)
at org.springframework.jndi.JndiObjectFactoryBean.lookupWithFallback(JndiObjectFactoryBean.java:231)
at org.springframework.jndi.JndiObjectFactoryBean.afterPropertiesSet(JndiObjectFactoryBean.java:217)
The fun this is that it's actual just for name "datasource.xml". If I change it to some other name the file will be deployed without any problems.
Seems "datasource.xml" is hardcoded in some way in embedded container.
Sample code:
System.setProperty("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
System.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
Embedded container; // initialized with Spring <bean id="container" class="org.jboss.jca.embedded.EmbeddedFactory" factory-method="create"/>
container.startup();
container.deploy("jdbc-xa.rar");
container.deploy("datasource.xml");
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (WFLY-4588) Elytron Integration
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-4588:
--------------------------------------
Summary: Elytron Integration
Key: WFLY-4588
URL: https://issues.jboss.org/browse/WFLY-4588
Project: WildFly
Issue Type: Task
Components: Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Blocker
Fix For: 10.0.0.CR1
Building on WFCORE-673 this is the top level task to cover integration in WildFly
The majority should be building on top of the work in core but there will be some WildFly specifics to consider.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (WFCORE-673) Elytron Integration with Core
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-673:
---------------------------------------
Summary: Elytron Integration with Core
Key: WFCORE-673
URL: https://issues.jboss.org/browse/WFCORE-673
Project: WildFly Core
Issue Type: Task
Components: Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Blocker
Fix For: 2.0.0.CR1
This is the top level tracking task for Elytron integration within core. The tasks for the changes actually being made will either be linked or added as sub-tasks.
In addition to this general issues that affect the Elytron integration are being labelled with 'affects_elytron' and can be queried using the following query: -
https://issues.jboss.org/issues/?filter=12323574
The label is a general catch-all for issues that are of interest to us but are not automatically blockers for our progress.
The general criteria for the resolution of this issue will be: -
- Inclusion of the Elytron Subsystem in core
- All network entry points in core to be securable using Elytron
- All SSL artefacts to be obtainable from Elytron.
Note: The legacy modes will become better defined as we progress but whilst it must be possible to use Elytron it's use may still be optional to a certain degree.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (JGRP-1910) MERGE3: Do not lose any members from view during a series of merges
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1910?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1910:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1189839|https://bugzilla.redhat.com/show_bug.cgi?id=1189839] from ASSIGNED to ON_QA
> MERGE3: Do not lose any members from view during a series of merges
> -------------------------------------------------------------------
>
> Key: JGRP-1910
> URL: https://issues.jboss.org/browse/JGRP-1910
> Project: JGroups
> Issue Type: Bug
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.3
>
> Attachments: SplitMergeFailFastTest.java, SplitMergeTest.java
>
>
> When connection between nodes is re-established, MERGE3 should merge the cluster together. This often does not involve a single MergeView but a series of such events. The problematic property of this protocol is that some of those views can lack certain members, though these are reachable.
> This causes problem in Infinispan since the cache cannot be fully rebalanced before another merge arrives, and all owners of certain segment can be gradually removed (and added again) to the view, while this is not detected as partition but crashed nodes -> losing all owners means data loss.
> Removing members from view should be the role of FDx protocols, not MERGEx.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (WFCORE-672) CLI tab-completion for attribute name path syntax
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFCORE-672:
----------------------------------------
Summary: CLI tab-completion for attribute name path syntax
Key: WFCORE-672
URL: https://issues.jboss.org/browse/WFCORE-672
Project: WildFly Core
Issue Type: Enhancement
Components: CLI
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
WFCORE-460 introduced support for attribute name path using dot and [i] index as name separators.
The goal of this issue is to provide tab-completion for this syntax based on the type and value-type description available for complex types.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (WFLY-4587) Provide a migration management operation for HornetQ to ActiveMQ Artemis
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-4587:
---------------------------------
Summary: Provide a migration management operation for HornetQ to ActiveMQ Artemis
Key: WFLY-4587
URL: https://issues.jboss.org/browse/WFLY-4587
Project: WildFly
Issue Type: Feature Request
Components: JMS
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 10.0.0.Alpha1
WildFly 10 has a new messaging-activemq subsystem using ActiveMQ Artemis as its messaging broker.
WildFly 10 needs to provide a :migrate management operation so that user upgrading from WildFly 9 to 10 can start WildFly 10 with their old configuration (which used HornetQ) and migrate to the new subsystem (which used ActiveMQ Artemis).
This migrate operation deals only with the management resource and does *not* migrate data from HornetQ to Artemis. This will done in a separate step (using either a JMS bridge or data export tool)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months
[JBoss JIRA] (WFLY-4586) Provide JMS backward compatibility
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-4586:
---------------------------------
Summary: Provide JMS backward compatibility
Key: WFLY-4586
URL: https://issues.jboss.org/browse/WFLY-4586
Project: WildFly
Issue Type: Sub-task
Components: JMS
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 10.0.0.Alpha1
New JMS clients (from WildFly 10) must be able to communicate with older WildFly 9 with HornetQ.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 2 months