[JBoss JIRA] (WFLY-1933) Disabled data-source without explicit enabled="false" in configuration xml file is re-enabled again after server reload
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1933?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1933:
-----------------------------------------------
Stefano Maestri <smaestri(a)redhat.com> made a comment on [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277]
Attention: Russel Dickenson
Release note text: enabled attribute is correctly marshaled on xml when :disable operation is used.
Let me know if you need something else.
> Disabled data-source without explicit enabled="false" in configuration xml file is re-enabled again after server reload
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1933
> URL: https://issues.jboss.org/browse/WFLY-1933
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Alpha4
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> The server automatically re-enables a data-source which was disabled before and which lost {{enabled="false"}} in the configuration XML file.
> There is a discrepancy between the default value of the {{enabled}} attribute in XSD and the same attribute definition in org.jboss.as.connector.subsystems.datasources.Constants. From my POV any data-source that has been disabled before should stay in that state unless it is explicitly enabled again. See https://bugzilla.redhat.com/show_bug.cgi?id=952277 for a reproducer.
> The culprit seems to be
> {code:java|title=org.jboss.as.connector.subsystems.datasources.DsParser}
> ...
> private void parseDataSource(final XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
> ValidateException {
> ...
> ==> boolean enabled = Defaults.ENABLED.booleanValue();
> ...
> private void parseXADataSource(XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
> ValidateException {
> ...
> ==> boolean enabled = Defaults.ENABLED.booleanValue();
> ...
> {code}
> Though it looks like a bug, I am not sure we can change the default value in XSD for EAP.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-1716) NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
by Oliver Pfau (JIRA)
[ https://issues.jboss.org/browse/WFLY-1716?page=com.atlassian.jira.plugin.... ]
Oliver Pfau commented on WFLY-1716:
-----------------------------------
Tried with wildfly 8.0.0 beta 2 build 773 and I get the exception:
08:43:28,204 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."my-war.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."my-war.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "my-war.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
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(Unknown Source) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_45]
Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache
at org.wildfly.extension.undertow.deployment.ELExpressionFactoryProcessor.deploy(ELExpressionFactoryProcessor.java:78)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
... 5 more
> NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache deploying ear with war inside
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-1716
> URL: https://issues.jboss.org/browse/WFLY-1716
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: 8.0.0.Alpha3
> Environment: Win 7, JEE 6, JDK 7
> Reporter: Oliver Pfau
> Assignee: Stuart Douglas
> Labels: Deploy, classnotfound, war
>
> I tried to deploy my ear which works in JBoss 7 in wildfly and got the following error on deploy:
> 09:59:55,060 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."my.ear"."mywar.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment "mywar.war" of deployment "my.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> 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: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache
> at org.wildfly.extension.undertow.deployment.ELExpressionFactoryProcessor.deploy(ELExpressionFactoryProcessor.java:78)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha3.jar:8.0.0.Alpha3]
> ... 5 more
> 09:59:55,100 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "my.ear")]) - failure description: {
> "JBAS014671: Failed services" => {"jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"my.ear\".\"mywar.war\".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of subdeployment \"mywar.war\" of deployment \"my.ear\"
> Caused by: java.lang.NoClassDefFoundError: org/jboss/el/cache/FactoryFinderCache"},
> "JBAS014771: Services with missing/unavailable dependencies" => [
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.ValidatorFactory is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.InstanceName is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
> "jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName.Validator is missing [jboss.naming.context.java.comp.my-service-ejb-x-SNAPSHOT.MyServiceName]",
>
> <all other services>
> ]
> }
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2125) wildfly8 can't identify port-offset
by Isa Isa (JIRA)
[ https://issues.jboss.org/browse/WFLY-2125?page=com.atlassian.jira.plugin.... ]
Isa Isa commented on WFLY-2125:
-------------------------------
Hi I am using wildfly-8.0.0.Beta1 and mod_cluster still does not picking up the port offset? It only identifies what is set in the standalone.xml.
If the offset is 100 then ajp would be 8109 which is does not identify, however if I set the ajp port in the standalone.xml to 8109 with no offset it works.
> wildfly8 can't identify port-offset
> -----------------------------------
>
> Key: WFLY-2125
> URL: https://issues.jboss.org/browse/WFLY-2125
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Alpha4
> Environment: wildfly-8.0.0.Alpha4.tar.gz
> jdk-7u25-linux-i586.rpm
> mod_cluster-1.2.0.Final-linux2-x64-ssl.tar.gz
> Reporter: hui gao
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.Beta1
>
>
> I installed wildfly8 and mod_cluster reference steps of https://docs.jboss.org/author/display/AS72/AS7+Cluster+Howto
> The cluster contains four servers,start up with domain mode:
> 10.19.222.52:server1/server2
> 10.19.222.53:server3/server4
> 10.19.222.50:apache
> But it only detects server1 and server3 which the port is 8009.
> The port-offset is 100,it can't identify the other port(8109) for server2 and server4.
> Search errorlog of Apache ,the proxy:AJP always acquired connection through initial AJP port(8009) defined in domain.xml.
> [Fri Sep 13 21:07:40 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:40 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=2644d861-0ead-352c-ba1e-619f1e1f25e8&Load=100"
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2366): manager_handler STATUS OK
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=ea81701b-f847-34a8-9534-0ac5c489af90&Load=100"
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
--
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
11 years, 2 months
[JBoss JIRA] (JGRP-1736) UDP: Android does not reset buffer length
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1736?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1736.
----------------------------
Resolution: Done
> UDP: Android does not reset buffer length
> -----------------------------------------
>
> Key: JGRP-1736
> URL: https://issues.jboss.org/browse/JGRP-1736
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.4.1, 3.5
>
>
> Discussion at http://jgroups.1086181.n5.nabble.com/jgroups-users-PLEASE-HELP-ME-OUT-FOR...:
> Hi, Belaban..I think I have found the problem...after discovering this issue occurs only on all ICS devices I have and after reading through the "Android issue #24748 DatagramPacket truncated UDP" at http://code.google.com/p/android/issues/detail?id=24748, I have introduced the following modification at org.jgroups.protocols.UDP.java:
> public void run() {
> final byte receive_buf[]=new byte[66000]; // to be on the safe side (IPv6 == 65575 bytes, IPv4 = 65535)
> final DatagramPacket packet=new DatagramPacket(receive_buf, receive_buf.length);
> while(thread != null && Thread.currentThread().equals(thread)) {
> try {
>
> //Solved Android ISSUE #24748 - DatagramPacket truncated UDP in ICS
> if (Util.checkForAndroid())
> packet.setLength(receive_buf.length);
>
> receiver_socket.receive(packet);
> int len=packet.getLength();
>
> ...
> }
> catch(SocketException sock_ex) {
> ...
> }
> catch(Throwable ex) {
> ...
> }
> }
> ...
> }
> It seems to solve the EOFException but I am not sure the real impact on Jgroups library as a whole.
--
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
11 years, 2 months
[JBoss JIRA] (JGRP-1736) UDP: Android does not reset buffer length
by Bela Ban (JIRA)
Bela Ban created JGRP-1736:
------------------------------
Summary: UDP: Android does not reset buffer length
Key: JGRP-1736
URL: https://issues.jboss.org/browse/JGRP-1736
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Minor
Fix For: 3.4.1, 3.5
Discussion at http://jgroups.1086181.n5.nabble.com/jgroups-users-PLEASE-HELP-ME-OUT-FOR...:
Hi, Belaban..I think I have found the problem...after discovering this issue occurs only on all ICS devices I have and after reading through the "Android issue #24748 DatagramPacket truncated UDP" at http://code.google.com/p/android/issues/detail?id=24748, I have introduced the following modification at org.jgroups.protocols.UDP.java:
public void run() {
final byte receive_buf[]=new byte[66000]; // to be on the safe side (IPv6 == 65575 bytes, IPv4 = 65535)
final DatagramPacket packet=new DatagramPacket(receive_buf, receive_buf.length);
while(thread != null && Thread.currentThread().equals(thread)) {
try {
//Solved Android ISSUE #24748 - DatagramPacket truncated UDP in ICS
if (Util.checkForAndroid())
packet.setLength(receive_buf.length);
receiver_socket.receive(packet);
int len=packet.getLength();
...
}
catch(SocketException sock_ex) {
...
}
catch(Throwable ex) {
...
}
}
...
}
It seems to solve the EOFException but I am not sure the real impact on Jgroups library as a whole.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-1070) Add a redirect-socket configuration to the web connector config
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1070?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1070:
-----------------------------------------------
Osamu Nagano <onagano(a)redhat.com> made a comment on [bug 900786|https://bugzilla.redhat.com/show_bug.cgi?id=900786]
Property substitution like 'redirect-port="${jb.redirect.port:8180}"' can be a workaround but of course unifying in socket-binding is smarter.
> Add a redirect-socket configuration to the web connector config
> ---------------------------------------------------------------
>
> Key: WFLY-1070
> URL: https://issues.jboss.org/browse/WFLY-1070
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Jean-Frederic Clere
>
> Support configuring a connector on the http socket and then redirect to the https socket without having to specify the actual port number outside of the socket-binding-group.
> The referenced forum thread has an example that uses "redirect-port" for this, but a new attribute would be needed, since changing the meaning of "redirect-port" would be incompatible.
>
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-1893) Restarting server with a disabled DS enables the DS
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1893?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1893:
-----------------------------------------------
Russell Dickenson <rdickens(a)redhat.com> made a comment on [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277]
Attention: Stefano Maestri
Can you please provide brief text appropriate to the Release Notes regarding this issue? I have looked over the code changes briefly but I cannot understand just how this issue was resolved.
> Restarting server with a disabled DS enables the DS
> ---------------------------------------------------
>
> Key: WFLY-1893
> URL: https://issues.jboss.org/browse/WFLY-1893
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Reporter: Kabir Khan
> Assignee: Stefano Maestri
>
> See https://issues.jboss.org/browse/WFLY-1874
> If you add a datasource with
> subsystem=datasources/data-source=Test:add(jndi-name=java:/Test,jta=false,use-ccm=false,connection-url=url,driver-class=org.h2.Driver,driver-name=h2,user-name=user,password=pass,validate-on-match=false,background-validation=false,share-prepared-statements=false)
> it shows up as not enabled/undefined:
> {code}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource{ "outcome" => "success",
> "result" => {
> ...
> "enabled" => false,
> {code}
> {code}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource(include-defaults=false)
> {
> "outcome" => "success",
> "result" => {
> ... "enabled" => undefined,
> {code}
> This is persisted as
> {code}
> <datasource jta="false" jndi-name="java:/Test" pool-name="Test" enabled="false" use-ccm="false">
> <connection-url>url</connection-url>
> <driver-class>org.h2.Driver</driver-class>
> <driver>h2</driver>
> <security>
> <user-name>user</user-name>
> <password>pass</password>
> </security>
> <validation>
> <validate-on-match>false</validate-on-match>
> <background-validation>false</background-validation>
> </validation>
> <statement>
> <share-prepared-statements>false</share-prepared-statements>
> </statement>
> </datasource>
> {code}
> Now if you stop and start the server again you end up with enabled=true.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-1933) Disabled data-source without explicit enabled="false" in configuration xml file is re-enabled again after server reload
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1933?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1933:
-----------------------------------------------
Russell Dickenson <rdickens(a)redhat.com> made a comment on [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277]
Attention: Stefano Maestri
Can you please provide brief text appropriate to the Release Notes regarding this issue? I have looked over the code changes briefly but I cannot understand just how this issue was resolved.
> Disabled data-source without explicit enabled="false" in configuration xml file is re-enabled again after server reload
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1933
> URL: https://issues.jboss.org/browse/WFLY-1933
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Alpha4
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> The server automatically re-enables a data-source which was disabled before and which lost {{enabled="false"}} in the configuration XML file.
> There is a discrepancy between the default value of the {{enabled}} attribute in XSD and the same attribute definition in org.jboss.as.connector.subsystems.datasources.Constants. From my POV any data-source that has been disabled before should stay in that state unless it is explicitly enabled again. See https://bugzilla.redhat.com/show_bug.cgi?id=952277 for a reproducer.
> The culprit seems to be
> {code:java|title=org.jboss.as.connector.subsystems.datasources.DsParser}
> ...
> private void parseDataSource(final XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
> ValidateException {
> ...
> ==> boolean enabled = Defaults.ENABLED.booleanValue();
> ...
> private void parseXADataSource(XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
> ValidateException {
> ...
> ==> boolean enabled = Defaults.ENABLED.booleanValue();
> ...
> {code}
> Though it looks like a bug, I am not sure we can change the default value in XSD for EAP.
--
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
11 years, 2 months
[JBoss JIRA] (JBASMP-58) jboss-as-maven-plugin freezes on authentication
by Julien Derveeuw (JIRA)
[ https://issues.jboss.org/browse/JBASMP-58?page=com.atlassian.jira.plugin.... ]
Julien Derveeuw updated JBASMP-58:
----------------------------------
Environment:
mac os x 10.8.5 & mac os x 10.9
mvn 3.1.1
was:mac os x 10.8.5
> jboss-as-maven-plugin freezes on authentication
> -----------------------------------------------
>
> Key: JBASMP-58
> URL: https://issues.jboss.org/browse/JBASMP-58
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Components: deploy
> Affects Versions: 7.5.Final
> Environment: mac os x 10.8.5 & mac os x 10.9
> mvn 3.1.1
> Reporter: Julien Derveeuw
> Assignee: James Perkins
> Priority: Critical
>
> I have jboss 7.1.1 in standalone mode running on machine A (linux).
> I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.
> If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.
> If I try to deploy from maven with this :
> {code:xml}
> <groupId>org.jboss.as.plugins</groupId>
> <artifactId>jboss-as-maven-plugin</artifactId>
> <version>7.5.Final</version>
> <configuration>
> <hostname>${deploy.jboss.host}</hostname>
> <port>${deploy.jboss.port}</port>
> <username>${deploy.jboss.user}</username>
> <password>${deploy.jboss.password}</password>
> </configuration>
> <executions>
> <execution>
> <phase>install</phase>
> <goals>
> <goal>deploy</goal>
> </goals>
> </execution>
> </executions>
> {code}
> plugin freezes indefinitely on
> {{Authenticating against security realm: ManagementRealm}}
> No more details are available with {{mvn -X}}
> If I remove the password or username from pom, it fails correctly with :
> {{The connection failed: Authentication failed: all available authentication mechanisms failed}}
> so it seems that the plugin somehow manages to connect to machine A.
> After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7@macosx is said to be buggy but it didn't help.
> More details :
> {code:title=mvn 3.1.1 output|borderStyle=solid}Nov 7, 2013 10:40:09 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.3.GA
> Authenticating against security realm: ManagementRealm
> {code}
> {code:title=jstack 7.1.1.Final|borderStyle=solid}
> "main" prio=5 tid=7f86d6800800 nid=0x1060f0000 in Object.wait() [1060ee000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:363)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:317)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:137)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:81)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.exists(StandaloneDeployment.java:175)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.createPlan(StandaloneDeployment.java:108)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.execute(StandaloneDeployment.java:133)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:138)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> {code:title=jstack 7.5.Final|borderStyle=solid}
> "main" prio=5 tid=7fceea001000 nid=0x10d4d0000 in Object.wait() [10d4ce000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:234)
> at org.jboss.as.plugin.common.AbstractServerConnection.getClient(AbstractServerConnection.java:156)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:133)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.deployment.AbstractDeployment.validate(AbstractDeployment.java:192)
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.deployment.AbstractAppDeployment.doExecute(AbstractAppDeployment.java:70)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:111)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
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
11 years, 2 months