[JBoss JIRA] (WFLY-9133) Wildfly 10.1.0 add-user command
by Bobby Bassman (JIRA)
Bobby Bassman created WFLY-9133:
-----------------------------------
Summary: Wildfly 10.1.0 add-user command
Key: WFLY-9133
URL: https://issues.jboss.org/browse/WFLY-9133
Project: WildFly
Issue Type: Bug
Components: ConfigAdmin
Affects Versions: 10.1.0.Final
Environment: Windows 10 64 bit
Wildfly 10.1.0
Reporter: Bobby Bassman
Assignee: Thomas Diesler
If Wildfly 10 does not initially have the 'admin' user. It must be created using the 'add-user' command line. When the command ('add-user') is used, without any warning, it may update the property files belonging to a different Jboss installation, rendering that installation broken.
This is because 'add-user' relies on environment variable 'JBOSS_HOME' - which may be set to a JBoss installation other than the Wildfly installation to which the 'add-user' command applies.
It appears that 'add-user.bat' has some code to detect this scenario, but it didn't work.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-9132) Applications won't deploy if their persistence.xml have multiple persistence units
by Bobby Bassman (JIRA)
Bobby Bassman created WFLY-9132:
-----------------------------------
Summary: Applications won't deploy if their persistence.xml have multiple persistence units
Key: WFLY-9132
URL: https://issues.jboss.org/browse/WFLY-9132
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 10.1.0.Final
Environment: Windows 10 64 bit
Wildfly 10.1.0
Reporter: Bobby Bassman
Assignee: Scott Marlow
Applications won't deploy if their persistence.xml have multiple persistence units. This was not a problem with EAP. Now, Wildfly requires that each @PersistenceContext have a 'unitName' parameter. WIth EAP 6.4, if a @PersistenceContext did not have a 'unitName' parameter, then the default PU was used. By requiring that @PersistenceUnit have 'unitName', developers are forced to unnecessarily bind Java code to configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (JBMESSAGING-1962) javax.jms.JMSException: Failed to route Reference[6147840512252321]:RELIABLE to dmEventTopic
by Tony Fan (JIRA)
Tony Fan created JBMESSAGING-1962:
-------------------------------------
Summary: javax.jms.JMSException: Failed to route Reference[6147840512252321]:RELIABLE to dmEventTopic
Key: JBMESSAGING-1962
URL: https://issues.jboss.org/browse/JBMESSAGING-1962
Project: JBoss Messaging
Issue Type: Release
Components: Messaging Core
Affects Versions: 1.4.8.SP9
Reporter: Tony Fan
System running for couple days then we see following error from server.log:
017-07-24 19:07:05,093 ERROR [com.ilrd.gem.plaf.dm.util.DmMessageSender] Caught MessageSenderException while attempting to send value object message
com.ilrd.gem.plaf.dm.messaging.MessageSenderException: Unable to send message.
at com.ilrd.gem.plaf.dm.messaging.JmsMessageSender.sendMessage(JmsMessageSender.java:238)
at com.ilrd.gem.plaf.dm.util.DmMessageSender.doSendValueObjectMessage(DmMessageSender.java:290)
at com.ilrd.gem.plaf.dm.util.DmMessageSender.sendMessageFromQueue(DmMessageSender.java:256)
at com.ilrd.gem.plaf.dm.util.DmMessageSender.processMessageQueue(DmMessageSender.java:237)
at com.ilrd.gem.plaf.dm.util.DmMessageSender.access$000(DmMessageSender.java:35)
at com.ilrd.gem.plaf.dm.util.DmMessageSender$1.run(DmMessageSender.java:87)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.jms.JMSException: Failed to route Reference[6147840512252321]:RELIABLE to dmEventTopic
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:791)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:437)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:87)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_7280680627620114891.invokeTarget(SessionAdvised$send_7280680627620114891.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspect.java:162)
at sun.reflect.GeneratedMethodAccessor365.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:122)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvised.java)
at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendRequest.java:95)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:165)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:967)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:2084)
at org.jboss.remoting.Client.invoke(Client.java:879)
at org.jboss.remoting.Client.invoke(Client.java:867)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160)
at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$send$aop(ClientSessionDelegate.java:499)
at org.jboss.jms.client.delegate.ClientSessionDelegate$send_6145266547759487588.invokeTarget(ClientSessionDelegate$send_6145266547759487588.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.jms.client.container.SessionAspect.handleSend(SessionAspect.java:694)
at org.jboss.aop.advice.org.jboss.jms.client.container.SessionAspect_z_handleSend_16166428.invoke(SessionAspect_z_handleSend_16166428.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientSessionDelegate.send(ClientSessionDelegate.java)
at org.jboss.jms.client.container.ProducerAspect.handleSend(ProducerAspect.java:276)
at org.jboss.aop.advice.org.jboss.jms.client.container.ProducerAspect_z_handleSend_16166428.invoke(ProducerAspect_z_handleSend_16166428.java)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientProducerDelegate.send(ClientProducerDelegate.java)
at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:165)
at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:208)
at org.jboss.jms.client.JBossMessageProducer.send(JBossMessageProducer.java:146)
at com.ilrd.gem.plaf.dm.messaging.JmsMessageSender.sendMessage(JmsMessageSender.java:203)
... 6 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3103) Embedded server doesn't close open file handles
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3103?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-12346 to WFCORE-3103:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3103 (was: JBEAP-12346)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
Modules
(was: CLI)
(was: Modules)
Affects Version/s: (was: 7.1.0.ER2)
> Embedded server doesn't close open file handles
> -----------------------------------------------
>
> Key: WFCORE-3103
> URL: https://issues.jboss.org/browse/WFCORE-3103
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Modules
> Reporter: Jan Blizňák
> Assignee: Brian Stansberry
>
> When embedded server is started programatically (eg. via CLI wrapper) with specified jboss home, JARs from that path are opened via classloader. But these open handles are never released even after embedded server is stopped.
> This causes problem in situation eg. when you want to delete that jboss home. This is exactly one of the scenarios used in EAP installer, you are not allowed to delete open files on Windows - see JBEAP-1404.
> I created a simple project that reproduce the issue with arbitrary EAP/WF distribution https://github.com/jbliznak/embedded-server-filelocking
> Run it with:
> mvn clean test "-Dwildfly.home=C:\dev\jboss-eap-7.1" "-Denforcer.skip" -Dtest=ModulesFileLockingTestCase
> Manual steps to reproduce in Java code:
> * start a CLI wrapper
> * start embed-server from given server path
> * stop embed-server
> * terminate CLI wrapper
> * try to delete given server path
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFCORE-3102) Implement the LocalClient close
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-3102:
-----------------------------------------
Summary: Implement the LocalClient close
Key: WFCORE-3102
URL: https://issues.jboss.org/browse/WFCORE-3102
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Affects Versions: 3.0.0.Beta28
Reporter: ehsavoie Hugonnet
Assignee: ehsavoie Hugonnet
Closing the LocalClient does nothing currently. It should interrupt all the operations it is executing
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months