[JBoss JIRA] (WFLY-4318) Do not force that the exploded directory ends with ".ear" to get the EJB's to deploy
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/WFLY-4318?page=com.atlassian.jira.plugin.... ]
Geoffrey De Smet updated WFLY-4318:
-----------------------------------
Description:
Relates to WFLY-4081 and the IntelliJ issues to make using WildFly less of a pain in IntelliJ:
https://youtrack.jetbrains.com/issue/IDEA-133729
https://youtrack.jetbrains.com/issue/IDEA-95695
"Checked solution in IntelliJ 14.1. In general it works. But there is problem with exploded EAR deployments. If I'm trying to deploy exploded EAR which contains some EJB jar with several EJBs beans, this EJBs fails to start in JBoss EAP: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor doesn't even start. But if I try to deploy exploded EAR with ".ear" postfix (just an output folder with ".ear" on the end) it successfully starts EJB beans and I see some JNDI mapping to it from "org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor". Maybe this is a problem of JBoss EAP itself but it seems that we cannot use just a regular folder for exploded EAR output, we have to add ".ear" suffix on the end :("
"For exploded EAR we should still add ".ear" extension to the exploded directory. Otherwise all EJB beans wouldn't be processed and started after deploy."
was:
Relates to WFLY-4081 and the IntelliJ issues to make using WildFly less of a pain in IntelliJ:
https://youtrack.jetbrains.com/issue/IDEA-133729
https://youtrack.jetbrains.com/issue/IDEA-95695
"Checked solution in 14.1. In general it works. But there is problem with exploded EAR deployments. If I'm trying to deploy exploded EAR which contains some EJB jar with several EJBs beans, this EJBs fails to start in JBoss EAP: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor doesn't even start. But if I try to deploy exploded EAR with ".ear" postfix (just an output folder with ".ear" on the end) it successfully starts EJB beans and I see some JNDI mapping to it from "org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor". Maybe this is a problem of JBoss EAP itself but it seems that we cannot use just a regular folder for exploded EAR output, we have to add ".ear" suffix on the end :("
"For exploded EAR we should still add ".ear" extension to the exploded directory. Otherwise all EJB beans wouldn't be processed and started after deploy."
> Do not force that the exploded directory ends with ".ear" to get the EJB's to deploy
> ------------------------------------------------------------------------------------
>
> Key: WFLY-4318
> URL: https://issues.jboss.org/browse/WFLY-4318
> Project: WildFly
> Issue Type: Bug
> Reporter: Geoffrey De Smet
> Assignee: Brian Stansberry
>
> Relates to WFLY-4081 and the IntelliJ issues to make using WildFly less of a pain in IntelliJ:
> https://youtrack.jetbrains.com/issue/IDEA-133729
> https://youtrack.jetbrains.com/issue/IDEA-95695
> "Checked solution in IntelliJ 14.1. In general it works. But there is problem with exploded EAR deployments. If I'm trying to deploy exploded EAR which contains some EJB jar with several EJBs beans, this EJBs fails to start in JBoss EAP: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor doesn't even start. But if I try to deploy exploded EAR with ".ear" postfix (just an output folder with ".ear" on the end) it successfully starts EJB beans and I see some JNDI mapping to it from "org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor". Maybe this is a problem of JBoss EAP itself but it seems that we cannot use just a regular folder for exploded EAR output, we have to add ".ear" suffix on the end :("
> "For exploded EAR we should still add ".ear" extension to the exploded directory. Otherwise all EJB beans wouldn't be processed and started after deploy."
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4318) Do not force that the exploded directory ends with ".ear" to get the EJB's to deploy
by Geoffrey De Smet (JIRA)
Geoffrey De Smet created WFLY-4318:
--------------------------------------
Summary: Do not force that the exploded directory ends with ".ear" to get the EJB's to deploy
Key: WFLY-4318
URL: https://issues.jboss.org/browse/WFLY-4318
Project: WildFly
Issue Type: Bug
Reporter: Geoffrey De Smet
Assignee: Brian Stansberry
Relates to WFLY-4081 and the IntelliJ issues to make using WildFly less of a pain in IntelliJ:
https://youtrack.jetbrains.com/issue/IDEA-133729
https://youtrack.jetbrains.com/issue/IDEA-95695
"Checked solution in 14.1. In general it works. But there is problem with exploded EAR deployments. If I'm trying to deploy exploded EAR which contains some EJB jar with several EJBs beans, this EJBs fails to start in JBoss EAP: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor doesn't even start. But if I try to deploy exploded EAR with ".ear" postfix (just an output folder with ".ear" on the end) it successfully starts EJB beans and I see some JNDI mapping to it from "org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor". Maybe this is a problem of JBoss EAP itself but it seems that we cannot use just a regular folder for exploded EAR output, we have to add ".ear" suffix on the end :("
"For exploded EAR we should still add ".ear" extension to the exploded directory. Otherwise all EJB beans wouldn't be processed and started after deploy."
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (REMJMX-93) Unable to connect over remjmx on ip6
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/REMJMX-93?page=com.atlassian.jira.plugin.... ]
Rob Stryker commented on REMJMX-93:
-----------------------------------
This seems to be a false alarm. Sorry for the spam. It seems when I added brackets, I included the port inside the brackets, which was incorrect.
Correct url is service:jmx:http-remoting-jmx://[fe80::5e51:4fff:fee6:e7ea]:9990
I will close this shortly if I am unable to replicate on any wildfly versions... For now it looks like it may just be a user error.
> Unable to connect over remjmx on ip6
> ------------------------------------
>
> Key: REMJMX-93
> URL: https://issues.jboss.org/browse/REMJMX-93
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Reporter: Rob Stryker
> Assignee: Darran Lofthouse
>
> Exception trace is as follows:
> {code}
> java.net.MalformedURLException: Bad port number: "": java.lang.NumberFormatException: For input string: ""
> at javax.management.remote.JMXServiceURL.<init>(JMXServiceURL.java:211)
> at org.jboss.ide.eclipse.as.jmx.integration.JBoss71ServerConnection.createConnection(JBoss71ServerConnection.java:85)
> {code}
> Code being run is basically:
> {code}
> String url = "service:jmx:http-remoting-jmx://fe80::5e51:4fff:fee6:e7ea:9990";
> JMXConnector connector = null;
> try {
> connector = JMXConnectorFactory.connect(new JMXServiceURL(url), environment);
> MBeanServerConnection connection = connector.getMBeanServerConnection();
> synchronized(this) {
> this.connectionToConnector.put(connection, connector);
> }
> return connection;
> } catch(IOException ioe) {
> {code}
> It's obvious that JMXServiceURL. is parsing the url based on the location of the colons and that ip6 urls, having many colons, is confusing it. But I'm not sure if this is a bug in JMXServiceURL for not properly handling ip6 or if this is a user error, ie, I'm not passing the proper url.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (REMJMX-93) Unable to connect over remjmx on ip6
by Rob Stryker (JIRA)
Rob Stryker created REMJMX-93:
---------------------------------
Summary: Unable to connect over remjmx on ip6
Key: REMJMX-93
URL: https://issues.jboss.org/browse/REMJMX-93
Project: Remoting JMX
Issue Type: Bug
Components: Connection
Reporter: Rob Stryker
Assignee: Darran Lofthouse
Exception trace is as follows:
{code}
java.net.MalformedURLException: Bad port number: "": java.lang.NumberFormatException: For input string: ""
at javax.management.remote.JMXServiceURL.<init>(JMXServiceURL.java:211)
at org.jboss.ide.eclipse.as.jmx.integration.JBoss71ServerConnection.createConnection(JBoss71ServerConnection.java:85)
{code}
Code being run is basically:
{code}
String url = "service:jmx:http-remoting-jmx://fe80::5e51:4fff:fee6:e7ea:9990";
JMXConnector connector = null;
try {
connector = JMXConnectorFactory.connect(new JMXServiceURL(url), environment);
MBeanServerConnection connection = connector.getMBeanServerConnection();
synchronized(this) {
this.connectionToConnector.put(connection, connector);
}
return connection;
} catch(IOException ioe) {
{code}
It's obvious that JMXServiceURL. is parsing the url based on the location of the colons and that ip6 urls, having many colons, is confusing it. But I'm not sure if this is a bug in JMXServiceURL for not properly handling ip6 or if this is a user error, ie, I'm not passing the proper url.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4314) Add blocking option to reload command for standalone server
by Tomas Rohovsky (JIRA)
[ https://issues.jboss.org/browse/WFLY-4314?page=com.atlassian.jira.plugin.... ]
Tomas Rohovsky edited comment on WFLY-4314 at 2/5/15 3:57 AM:
--------------------------------------------------------------
Brian thanks for the prompt answer. I tied to use reload without colon and I got {{Command execution failed for command 'reload'. Unsupported ModelControllerClient implementation org.jboss.as.plugin.cli.Commands$NonClosingModelControllerClient}}. It looks to be this issue JBASMP-59. I tried to execute it with jboss-cli.sh as well. The result was {{if request failed: JBAS013493: System boot is in process; execution of remote management operations is not currently available}}. Any of these two ways didn't changed standalone-full.xml.
was (Author: trohovsky):
Brian thanks for the prompt answer. I tied to use reload without colon and I got {{Command execution failed for command ' reload'. Unsupported ModelControllerClient implementation org.jboss.as.plugin.cli.Commands$NonClosingModelControllerClient}}. It looks to be this issue JBASMP-59. I tried to execute it with jboss-cli.sh as well. The result was {{if request failed: JBAS013493: System boot is in process; execution of remote management operations is not currently available}}. Any of these two ways didn't changed standalone-full.xml.
> Add blocking option to reload command for standalone server
> -----------------------------------------------------------
>
> Key: WFLY-4314
> URL: https://issues.jboss.org/browse/WFLY-4314
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: JBoss AS7 7.2.0.Final, 8.2.0.Final
> Reporter: Tomas Rohovsky
> Assignee: Brian Stansberry
>
> reload command is non-blocking which causes problems in CLI scripts. Let's take this as an example:
> {code}
> if (outcome == failed) of /subsystem=resource-adapters/resource-adapter=activemq-ra:read-resource
> /subsystem=resource-adapters/resource-adapter=activemq-ra:add(archive=activemq-ra.rar)
> :reload
> end-if
> {code}
> I use jboss-as-maven-plugin for its execution and sometimes I get: {{Command execution failed for command 'end-if'. if request failed: java.util.concurrent.ExecutionException: Operation failed: Channel closed}}
> This functionality has already been asked in WFLY-208, but for some reason it was implemented only for domain-related commands but not standalone-related (reload and shutdown).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4314) Add blocking option to reload command for standalone server
by Tomas Rohovsky (JIRA)
[ https://issues.jboss.org/browse/WFLY-4314?page=com.atlassian.jira.plugin.... ]
Tomas Rohovsky updated WFLY-4314:
---------------------------------
Description:
reload command is non-blocking which causes problems in CLI scripts. Let's take this as an example:
{code}
if (outcome == failed) of /subsystem=resource-adapters/resource-adapter=activemq-ra:read-resource
/subsystem=resource-adapters/resource-adapter=activemq-ra:add(archive=activemq-ra.rar)
:reload
end-if
{code}
I use jboss-as-maven-plugin for its execution and sometimes I get: {{Command execution failed for command 'end-if'. if request failed: java.util.concurrent.ExecutionException: Operation failed: Channel closed}}
This functionality has already been asked in WFLY-208, but for some reason it was implemented only for domain-related commands but not standalone-related (reload and shutdown).
was:
reload command is non-blocking which causes problems in CLI scripts. Let's take this as an example:
{code}
if (outcome == failed) of /subsystem=resource-adapters/resource-adapter=activemq-ra:read-resource
/subsystem=resource-adapters/resource-adapter=activemq-ra:add(archive=activemq-ra.rar)
:reload
end-if
{code}
I use jboss-as-maven-plugin for its execution and sometimes I get: {Command execution failed for command 'end-if'. if request failed: java.util.concurrent.ExecutionException: Operation failed: Channel closed}
This functionality has already been asked in WFLY-208, but for some reason it was implemented only for domain-related commands but not standalone-related (reload and shutdown).
> Add blocking option to reload command for standalone server
> -----------------------------------------------------------
>
> Key: WFLY-4314
> URL: https://issues.jboss.org/browse/WFLY-4314
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: JBoss AS7 7.2.0.Final, 8.2.0.Final
> Reporter: Tomas Rohovsky
> Assignee: Brian Stansberry
>
> reload command is non-blocking which causes problems in CLI scripts. Let's take this as an example:
> {code}
> if (outcome == failed) of /subsystem=resource-adapters/resource-adapter=activemq-ra:read-resource
> /subsystem=resource-adapters/resource-adapter=activemq-ra:add(archive=activemq-ra.rar)
> :reload
> end-if
> {code}
> I use jboss-as-maven-plugin for its execution and sometimes I get: {{Command execution failed for command 'end-if'. if request failed: java.util.concurrent.ExecutionException: Operation failed: Channel closed}}
> This functionality has already been asked in WFLY-208, but for some reason it was implemented only for domain-related commands but not standalone-related (reload and shutdown).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4314) Add blocking option to reload command for standalone server
by Tomas Rohovsky (JIRA)
[ https://issues.jboss.org/browse/WFLY-4314?page=com.atlassian.jira.plugin.... ]
Tomas Rohovsky commented on WFLY-4314:
--------------------------------------
Brian thanks for the prompt answer. I tied to use reload without colon and I got {{Command execution failed for command ' reload'. Unsupported ModelControllerClient implementation org.jboss.as.plugin.cli.Commands$NonClosingModelControllerClient}}. It looks to be this issue JBASMP-59. I tried to execute it with jboss-cli.sh as well. The result was {{if request failed: JBAS013493: System boot is in process; execution of remote management operations is not currently available}}. Any of these two ways didn't changed standalone-full.xml.
> Add blocking option to reload command for standalone server
> -----------------------------------------------------------
>
> Key: WFLY-4314
> URL: https://issues.jboss.org/browse/WFLY-4314
> Project: WildFly
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: JBoss AS7 7.2.0.Final, 8.2.0.Final
> Reporter: Tomas Rohovsky
> Assignee: Brian Stansberry
>
> reload command is non-blocking which causes problems in CLI scripts. Let's take this as an example:
> {code}
> if (outcome == failed) of /subsystem=resource-adapters/resource-adapter=activemq-ra:read-resource
> /subsystem=resource-adapters/resource-adapter=activemq-ra:add(archive=activemq-ra.rar)
> :reload
> end-if
> {code}
> I use jboss-as-maven-plugin for its execution and sometimes I get: {Command execution failed for command 'end-if'. if request failed: java.util.concurrent.ExecutionException: Operation failed: Channel closed}
> This functionality has already been asked in WFLY-208, but for some reason it was implemented only for domain-related commands but not standalone-related (reload and shutdown).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4188) Client Mapping expressions are allowed but are not resolved if used
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-4188?page=com.atlassian.jira.plugin.... ]
Chao Wang resolved WFLY-4188.
-----------------------------
Fix Version/s: 9.0.0.Beta1
Resolution: Done
> Client Mapping expressions are allowed but are not resolved if used
> -------------------------------------------------------------------
>
> Key: WFLY-4188
> URL: https://issues.jboss.org/browse/WFLY-4188
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, ConfigAdmin
> Affects Versions: 8.2.0.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Chao Wang
> Fix For: 9.0.0.Beta1
>
>
> If socket binding with client-mapping is used to provide a valid client address for EJB invocation to the client the expressions are not resolved.
> Depend on the attribute the parsing failed direct during startup (port# is not numeric) or the expression is send to the client where the Exception is thrown at runtime.
> Notice for EJB invocation the problem is only visible if the application is clustered, otherwise the cluster view (where the client-mapping take effect) is not send to the client.
> Dec 17, 2014 2:53:43 PM org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager getEJBReceiver
> INFO: Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='redhat', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='${jboss.node.name}', destinationPort=8080}], resolvedDestination=[Destination address=${jboss.node.name}, destination port=8080]} in cluster ejb
> java.lang.RuntimeException: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:77)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:102)
> at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
> at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:79)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:405)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:379)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133)
> at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:75)
> ... 8 more
> Caused by: java.net.URISyntaxException: Illegal character in authority at index 7: http://@${jboss.node.name}:8080/?#
> at java.net.URI$Parser.fail(URI.java:2829)
> at java.net.URI$Parser.parseAuthority(URI.java:3167)
> at java.net.URI$Parser.parseHierarchical(URI.java:3078)
> at java.net.URI$Parser.parse(URI.java:3034)
> at java.net.URI.<init>(URI.java:680)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:100)
> at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:215)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
> ... 12 more
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months