[JBoss JIRA] (WFLY-2591) CLI can not connect to the server started with port-offset
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2591:
-----------------------------------
Priority: Major (was: Blocker)
> CLI can not connect to the server started with port-offset
> ----------------------------------------------------------
>
> Key: WFLY-2591
> URL: https://issues.jboss.org/browse/WFLY-2591
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Beta1
> Environment: used actual WildFly Beta from github:
> commit 96160520ce245d6a85cbb77cad92a021564aa376
> Date: Wed Nov 20 17:05:00 2013 +0100
> Reporter: Wolf-Dieter Fink
> Assignee: Darran Lofthouse
>
> If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface.
> To reproduce start a WildFly Beta server (Alpha3 has the same problem)
> bin/standalone.sh -Djboss.socket.binding.port-offset=100
> and a cli client:
> bin/jboss-cli.sh -c --controller=localhost:10099
> It makes no difference whether the port is changed by port-offset or configuration.
> All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation.
> The server log an ERROR message:
> ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856
> The jboss-cli.sh client show:
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:292)
> at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238)
> ... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938)
> ... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166)
> at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 13 more
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> ... 23 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2591) CLI can not connect to the server started with port-offset
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-2591:
--------------------------------------
Assignee: Darran Lofthouse (was: Alexey Loubyansky)
> CLI can not connect to the server started with port-offset
> ----------------------------------------------------------
>
> Key: WFLY-2591
> URL: https://issues.jboss.org/browse/WFLY-2591
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Beta1
> Environment: used actual WildFly Beta from github:
> commit 96160520ce245d6a85cbb77cad92a021564aa376
> Date: Wed Nov 20 17:05:00 2013 +0100
> Reporter: Wolf-Dieter Fink
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface.
> To reproduce start a WildFly Beta server (Alpha3 has the same problem)
> bin/standalone.sh -Djboss.socket.binding.port-offset=100
> and a cli client:
> bin/jboss-cli.sh -c --controller=localhost:10099
> It makes no difference whether the port is changed by port-offset or configuration.
> All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation.
> The server log an ERROR message:
> ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856
> The jboss-cli.sh client show:
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:292)
> at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238)
> ... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938)
> ... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166)
> at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 13 more
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> ... 23 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (SECURITY-770) Support external password for keystore of PicketBoxVault implementation
by Peter Skopek (JIRA)
[ https://issues.jboss.org/browse/SECURITY-770?page=com.atlassian.jira.plug... ]
Peter Skopek commented on SECURITY-770:
---------------------------------------
The patch looks good. We can apply it.
> Support external password for keystore of PicketBoxVault implementation
> -----------------------------------------------------------------------
>
> Key: SECURITY-770
> URL: https://issues.jboss.org/browse/SECURITY-770
> Project: PicketBox
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Attachments: SECURITY-770_with_testcase.patch
>
>
> At the moment, the default implementation of Vault supports masked keystore password only. It would be nice to add a facility for external keystore password too so that customers can either define an external command to get the password or define their own class which provides a password for the keystore.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (JASSIST-210) MethodCall.replace() throws inconsistent stack height in certain scenarios
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-210?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-210:
---------------------------------------
For the same reason I mentioned in This is similar to https://issues.jboss.org/browse/JASSIST-52
substituting a try-catch block for an argument or an operand in an expression is not possible (as far as I know).
The only workaround is to throw an exception again (or return a value) at the end of the catch clause.
If you execute ref.testMethod1(ref.testMethod2), then
1: ref is pushed onto the stack
2: ref is pushed onto the stack (for calling testMethod2)
3: invoke testMethod2, which push a return value onto the stack
4: pop the two values from the stack and invoke testMethod1
After the translation, 2 and 3 are replaced with a try-catch statement.
If an exception is thrown in the try block, then *all* the values in the stack are popped out.
So the value of ref stored in 1 is also popped out.
That's why even if the catch block pushed some value onto the stack, the JVM reports a verification error.
The value of ref is missing.
> MethodCall.replace() throws inconsistent stack height in certain scenarios
> --------------------------------------------------------------------------
>
> Key: JASSIST-210
> URL: https://issues.jboss.org/browse/JASSIST-210
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA, 3.18.1-GA
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> Tested on 3.16.1-GA
> This is similar to https://issues.jboss.org/browse/JASSIST-52, but the try-catch block usage is different (not wrapping the $proceed($$))
> Based on the javassist tutorial, the substituted code for MethodCall.replace():
> {{Note that the substituted code is not an expression but a statement or a block. It cannot be or contain a try-catch statement.}}
> However in the case that try-catch does not wrap the $_=$proceed($$);
> It seems to work properly. For example:
> ctClass.instrument(new ExprEditor() {
> public void edit(MethodCall m) throws CannotCompileException {
> if (m.getMethodName().equals("testMethod2")) {
> String newBlock = "{ try { System.out.println(\"injected\"); } catch (Exception e) { e.printStackTrace(); } $_ = $proceed($$); }";
> m.replace(newBlock);
> }
> }
> });
> {{which ctClass is class TestReplace, which has code as below:}}
> public class TestReplace {
> public static void main(String[] args) {
> RefClass ref = new RefClass();
> ref.testMethod2();
> }
> }
> class RefClass {
> public void testMethod1(Object o) {}
> public Object testMethod2() { return null; }
> }
> {{running TestReplace with the modified bytecode correctly prints "injected" to the screen. However if I add one more line to the TestReplace's main() method}}
> ref.testMethod1(ref.testMethod2());
> {{It throws exception as below}}
> javassist.bytecode.BadBytecode: inconsistent stack height -1
> javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:106)
> *So is try-catch acceptable if it does not wrap the $_=$proceed($$)? If so, is it a bug if it does not work properly for method invocation within another method invocation?*
> Many thanks in advance!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-2426:
------------------------------------
It's in a profile, which can be disabled by -DnoVersion.properties
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
> Labels: build, integration, jbds, layers, version
> Fix For: 8.0.0.CR1
>
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (JASSIST-210) MethodCall.replace() throws inconsistent stack height in certain scenarios
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-210?page=com.atlassian.jira.plugi... ]
Shigeru Chiba resolved JASSIST-210.
-----------------------------------
Resolution: Unresolved
> MethodCall.replace() throws inconsistent stack height in certain scenarios
> --------------------------------------------------------------------------
>
> Key: JASSIST-210
> URL: https://issues.jboss.org/browse/JASSIST-210
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.16.1-GA, 3.18.1-GA
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> Tested on 3.16.1-GA
> This is similar to https://issues.jboss.org/browse/JASSIST-52, but the try-catch block usage is different (not wrapping the $proceed($$))
> Based on the javassist tutorial, the substituted code for MethodCall.replace():
> {{Note that the substituted code is not an expression but a statement or a block. It cannot be or contain a try-catch statement.}}
> However in the case that try-catch does not wrap the $_=$proceed($$);
> It seems to work properly. For example:
> ctClass.instrument(new ExprEditor() {
> public void edit(MethodCall m) throws CannotCompileException {
> if (m.getMethodName().equals("testMethod2")) {
> String newBlock = "{ try { System.out.println(\"injected\"); } catch (Exception e) { e.printStackTrace(); } $_ = $proceed($$); }";
> m.replace(newBlock);
> }
> }
> });
> {{which ctClass is class TestReplace, which has code as below:}}
> public class TestReplace {
> public static void main(String[] args) {
> RefClass ref = new RefClass();
> ref.testMethod2();
> }
> }
> class RefClass {
> public void testMethod1(Object o) {}
> public Object testMethod2() { return null; }
> }
> {{running TestReplace with the modified bytecode correctly prints "injected" to the screen. However if I add one more line to the TestReplace's main() method}}
> ref.testMethod1(ref.testMethod2());
> {{It throws exception as below}}
> javassist.bytecode.BadBytecode: inconsistent stack height -1
> javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:106)
> *So is try-catch acceptable if it does not wrap the $_=$proceed($$)? If so, is it a bug if it does not work properly for method invocation within another method invocation?*
> Many thanks in advance!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka resolved WFLY-2426.
--------------------------------
Labels: build integration jbds layers version (was: )
Fix Version/s: 8.0.0.CR1
Resolution: Done
Resolving this and expecting some feedback.
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
> Labels: version, layers, jbds, integration, build
> Fix For: 8.0.0.CR1
>
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2426) Easily accessible static information describing the release
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2426?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-2426:
------------------------------------
I don't like the solution with file buried somewhere in the dir structure which is not even guaranteed to remain as is for future releases.
I've created the two PR's - 5551 and 5552, two impls of the same - adding version-base.txt.
Currently it uses ${project.version}. Is maitaining the version string manually necessary? IMO we should rely on the version from POM.
The name is version-base.properties.
1) it clearly declares the file format,
2) it declares that it's for the "base" layer.
Ad 2) - for other layers, another file would be added. This ensures that tools only looking for AS will find it, and it's version. Tools looking for all layers may simply check for version-*.properties, just like they would check for "modules/system/layers/" + layer + ...
> Easily accessible static information describing the release
> -----------------------------------------------------------
>
> Key: WFLY-2426
> URL: https://issues.jboss.org/browse/WFLY-2426
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Ondrej Zizka
>
> Tools that work with a WF installation need to identify what they are working with before they can launch or interact with the server. Specifically, they need to know the version. They likely need to know other information as well, such as the name of the software; e.g. whether it is WildFly itself or some other project based on WildFly.
> This information should be provided in standard format in a text file in a standard location in the distribution (probably in bin). The text file should be generated as part of the build.
> The solution to this issue should consider the requirements of other "identities" that may be based on WildFly. See [1] for the definition of an identity.
> The solution to this issue should consider the needs of products based on WildFly and other non-product identities. For example, can the existing product.conf contain the necessary information for a product, with some differently named but largely equivalent file being used in a non-product distribution?
> The solution to this issue should consider the implications for the patching tool.
> [1] https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganiz... for
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-2228) EJB and web module cannot have the same name in an ear
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2228?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-2228:
---------------------------------------
This issue was marked as duplicate of WFLY-2223 , which is already resolved. If you are still suffering from this on a Wildfly build made from current sources then please let us know in WFLY-2223.
> EJB and web module cannot have the same name in an ear
> ------------------------------------------------------
>
> Key: WFLY-2228
> URL: https://issues.jboss.org/browse/WFLY-2228
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Beta1
> Reporter: Jozef Hartinger
> Assignee: Eduardo Martins
> Fix For: 8.0.0.CR1
>
> Attachments: weld-translator.ear
>
>
> Having an ear project like this:
> {code}
> weld.translator.ear
> +--weld-translator.war
> +--weld-translator.jar
> {code}
> I am no longer able to deploy it to WildFly. This is a regression caused by the following commit: https://github.com/wildfly/wildfly/commit/d4aecbe5d2b241befa5da43b19c2d07...
> The deployment exception:
> {noformat}
> 10:45:56,835 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: WildFly 8.0.0.Beta1 "WildFly" started in 3433ms - Started 180 of 217 services (62 services are lazy, passive or on-demand)
> 10:46:22,816 INFO [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/41/4cdfd11cd5283d5356778f396c618ca2477c6b/content
> 10:46:22,842 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:46:22,912 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "null" (runtime-name: "weld-jsf-translator-war-2.1.0-SNAPSHOT.war")
> 10:46:22,912 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015876: Starting deployment of "null" (runtime-name: "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar")
> 10:46:23,147 INFO [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016002: Processing weld deployment weld-translator.ear
> 10:46:23,192 INFO [org.hibernate.validator.internal.util.Version] (MSC service thread 1-8) HV000001: Hibernate Validator 5.0.1.Final
> 10:46:23,340 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016002: Processing weld deployment weld-jsf-translator-war-2.1.0-SNAPSHOT.war
> 10:46:23,353 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016002: Processing weld deployment weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar
> 10:46:23,366 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-6) JNDI bindings for session bean named TranslatorControllerBean in deployment unit subdeployment "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar" of deployment "weld-translator.ear" are as follows:
> java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:module/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean
> java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/TranslatorControllerBean
> java:module/TranslatorControllerBean
> 10:46:23,369 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-6) JNDI bindings for session bean named SentenceTranslator in deployment unit subdeployment "weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar" of deployment "weld-translator.ear" are as follows:
> java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:module/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:global/weld-translator/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator
> java:app/weld-jsf-translator-ejb-2.1.0-SNAPSHOT/SentenceTranslator
> java:module/SentenceTranslator
> 10:46:23,392 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: weld-translator.ear
> 10:46:23,430 INFO [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900: 2.1.0 (2013-10-07 08:46)
> 10:46:23,448 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016008: Starting weld service for deployment weld-translator.ear
> 10:46:24,654 INFO [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-8) Initializing Mojarra 2.2.3-jbossorg-1 20130910-1739 for context '/weld-translator'
> 10:46:25,490 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) JBAS018210: Register web context: /weld-translator
> 10:46:25,569 INFO [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "weld-translator.ear" (runtime-name : "weld-translator.ear")
> 10:46:43,715 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) JBAS018224: Unregister web context: /weld-translator
> 10:46:43,731 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) JBAS016009: Stopping weld service for deployment weld-translator.ear
> 10:46:43,775 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: weld-jsf-translator-ejb-2.1.0-SNAPSHOT.jar) in 65ms
> 10:46:43,777 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment null (runtime-name: weld-jsf-translator-war-2.1.0-SNAPSHOT.war) in 68ms
> 10:46:43,779 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment weld-translator.ear (runtime-name: weld-translator.ear) in 70ms
> 10:46:43,820 INFO [org.jboss.as.repository] (management-handler-thread - 2) JBAS014901: Content removed from location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/41/4cdfd11cd5283d5356778f396c618ca2477c6b/content
> 10:46:43,821 INFO [org.jboss.as.server] (management-handler-thread - 2) JBAS018558: Undeployed "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:47:10,201 INFO [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content added at location /home/jharting/jboss/Weld/wildfly-8.0.0.Beta1/standalone/data/content/d9/22ca6b33304b2cccc227cdf8f6aadeedad88f9/content
> 10:47:10,203 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "weld-translator.ear" (runtime-name: "weld-translator.ear")
> 10:47:10,223 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "null" (runtime-name: "weld-translator.jar")
> 10:47:10,223 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015876: Starting deployment of "null" (runtime-name: "weld-translator.war")
> 10:47:10,297 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016002: Processing weld deployment weld-translator.ear
> 10:47:10,310 INFO [org.jboss.weld.deployer] (MSC service thread 1-6) JBAS016002: Processing weld deployment weld-translator.war
> 10:47:10,311 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment weld-translator.jar
> 10:47:10,314 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named TranslatorControllerBean in deployment unit subdeployment "weld-translator.jar" of deployment "weld-translator.ear" are as follows:
> java:global/weld-translator/weld-translator.jar/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:app/weld-translator.jar/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:module/TranslatorControllerBean!org.jboss.weld.examples.translator.TranslatorController
> java:global/weld-translator/weld-translator.jar/TranslatorControllerBean
> java:app/weld-translator.jar/TranslatorControllerBean
> java:module/TranslatorControllerBean
> 10:47:10,314 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named SentenceTranslator in deployment unit subdeployment "weld-translator.jar" of deployment "weld-translator.ear" are as follows:
> java:global/weld-translator/weld-translator.jar/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:app/weld-translator.jar/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:module/SentenceTranslator!org.jboss.weld.examples.translator.Translator
> java:global/weld-translator/weld-translator.jar/SentenceTranslator
> java:app/weld-translator.jar/SentenceTranslator
> java:module/SentenceTranslator
> 10:47:10,318 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "weld-translator.jar" of deployment "weld-translator.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered
> at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2384) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.setupConcurrentContext(EEConcurrentContextProcessor.java:110)
> at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.processModuleDescription(EEConcurrentContextProcessor.java:71)
> at org.jboss.as.ee.concurrent.deployers.EEConcurrentContextProcessor.deploy(EEConcurrentContextProcessor.java:54)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1]
> ... 5 more
> 10:47:10,329 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "weld-translator.ear")]) - failure description: {
> "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"weld-translator.jar\" of deployment \"weld-translator.ear\"
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered"},
> "JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.deployment.unit.\"weld-translator.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"weld-translator.ear\".beanmanager]",
> "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".batch is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]",
> "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]"
> ]
> }
> 10:47:10,338 ERROR [org.jboss.as.server] (management-handler-thread - 3) JBAS015870: Deploy of deployment "weld-translator.ear" was rolled back with the following failure message:
> {
> "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.jar\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"weld-translator.jar\" of deployment \"weld-translator.ear\"
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.concurrent.ee.context.config.weld-translator.weld-translator is already registered"},
> "JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.deployment.unit.\"weld-translator.ear\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"weld-translator.ear\".beanmanager]",
> "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".batch is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]",
> "jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"weld-translator.ear\".\"weld-translator.war\".beanmanager]"
> ]
> }
> 10:47:10,351 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment null (runtime-name: weld-translator.jar) in 18ms
> 10:47:10,354 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment null (runtime-name: weld-translator.war) in 21ms
> 10:47:10,356 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment weld-translator.ear (runtime-name: weld-translator.ear) in 23ms
> 10:47:10,358 INFO [org.jboss.as.controller] (management-handler-thread - 3) JBAS014774: Service status report
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".beanmanager (missing) dependents: [service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".weld.weldClassIntrospector, service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".batch]
> service jboss.deployment.unit."weld-translator.ear".beanmanager (missing) dependents: [service jboss.deployment.unit."weld-translator.ear".weld.weldClassIntrospector]
> service jboss.naming.context.java.module.weld-translator."weld-translator.war" (missing) dependents: [service jboss.deployment.subunit."weld-translator.ear"."weld-translator.war".INSTALL]
> JBAS014777: Services which failed to start: service jboss.deployment.subunit."weld-translator.ear"."weld-translator.jar".POST_MODULE
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months