[JBoss JIRA] (JBWEB-292) Http11Nio loaded, JBWEB002081: No cipher match
by Michal Babacek (JIRA)
[ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.... ]
Michal Babacek updated JBWEB-292:
---------------------------------
Summary: Http11Nio loaded, JBWEB002081: No cipher match (was: Http11Nio loaded even with native="false", JBWEB002081: No cipher match)
> Http11Nio loaded, JBWEB002081: No cipher match
> ----------------------------------------------
>
> Key: JBWEB-292
> URL: https://issues.jboss.org/browse/JBWEB-292
> Project: JBoss Web
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.4.0.GA
> Reporter: Michal Babacek
> Assignee: Remy Maucherat
> Priority: Critical
> Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient"
> password="tomcat"
> certificate-key-file="/tmp/ews-eap6/client-cert-key.jks"
> cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL"
> ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
> />
> </mod-cluster-config>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
> <ssl name="https"
> key-alias="javaclient"
> password="tomcat"
> certificate-key-file="/tmp/ews-eap6/client-cert-key.jks"
> cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL"
> protocol="TLS" verify-client="false"
> certificate-file="/tmp/ews-eap6/client-cert-key.jks"
> ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, even if natives are unpacked in {{modules/system/layers/base/org/jboss/as/web/main/lib/linux-x86_64/libtcnative-1.so}}, because there is {{native="false"}} in the web subsystem configuration, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}} despite having {{native="false"}}.
> This causes cipher suite errors, because the native implementation doesn't know what to do with it...
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
> at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
> at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> ... 9 more
> 06:18:26,663 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException: JBWEB000023: Protocol handler initialization failed
> at org.apache.catalina.connector.Connector.init(Connector.java:985)
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
> ... 5 more
> {noformat}
> Any ideas?
--
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
12 years, 4 months
[JBoss JIRA] (JBWEB-292) Http11Nio loaded even with native="false", JBWEB002081: No cipher match
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBWEB-292?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JBWEB-292:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1073430
> Http11Nio loaded even with native="false", JBWEB002081: No cipher match
> -----------------------------------------------------------------------
>
> Key: JBWEB-292
> URL: https://issues.jboss.org/browse/JBWEB-292
> Project: JBoss Web
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.4.0.GA
> Reporter: Michal Babacek
> Assignee: Remy Maucherat
> Priority: Critical
> Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys,
> I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config advertise-socket="modcluster" connector="https">
> <dynamic-load-provider>
> <load-metric type="busyness"/>
> </dynamic-load-provider>
> <ssl key-alias="javaclient"
> password="tomcat"
> certificate-key-file="/tmp/ews-eap6/client-cert-key.jks"
> cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL"
> ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
> />
> </mod-cluster-config>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
> <ssl name="https"
> key-alias="javaclient"
> password="tomcat"
> certificate-key-file="/tmp/ews-eap6/client-cert-key.jks"
> cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL"
> protocol="TLS" verify-client="false"
> certificate-file="/tmp/ews-eap6/client-cert-key.jks"
> ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, even if natives are unpacked in {{modules/system/layers/base/org/jboss/as/web/main/lib/linux-x86_64/libtcnative-1.so}}, because there is {{native="false"}} in the web subsystem configuration, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}} despite having {{native="false"}}.
> This causes cipher suite errors, because the native implementation doesn't know what to do with it...
> * EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
> * EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
> {noformat}
> 06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
> at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.io.IOException: JBWEB002081: No cipher match
> at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> ... 9 more
> 06:18:26,663 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: LifecycleException: JBWEB000023: Protocol handler initialization failed
> at org.apache.catalina.connector.Connector.init(Connector.java:985)
> at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
> ... 5 more
> {noformat}
> Any ideas?
--
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
12 years, 4 months
[JBoss JIRA] (JBWEB-292) Http11Nio loaded even with native="false", JBWEB002081: No cipher match
by Michal Babacek (JIRA)
Michal Babacek created JBWEB-292:
------------------------------------
Summary: Http11Nio loaded even with native="false", JBWEB002081: No cipher match
Key: JBWEB-292
URL: https://issues.jboss.org/browse/JBWEB-292
Project: JBoss Web
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: JBossWeb-7.4.0.GA
Reporter: Michal Babacek
Assignee: Remy Maucherat
Priority: Critical
Fix For: JBossWeb-7.4.0.GA
Hi guys,
I have an SSL test that sets up the web subsystem with HTTPS connector only and uses HTTPS with mod_cluster.
{code}
<subsystem xmlns="urn:jboss:domain:modcluster:1.2">
<mod-cluster-config advertise-socket="modcluster" connector="https">
<dynamic-load-provider>
<load-metric type="busyness"/>
</dynamic-load-provider>
<ssl key-alias="javaclient"
password="tomcat"
certificate-key-file="/tmp/ews-eap6/client-cert-key.jks"
cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL"
ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"
/>
</mod-cluster-config>
</subsystem>
<subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true" enabled="true">
<ssl name="https"
key-alias="javaclient"
password="tomcat"
certificate-key-file="/tmp/ews-eap6/client-cert-key.jks"
cipher-suite="AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL"
protocol="TLS" verify-client="false"
certificate-file="/tmp/ews-eap6/client-cert-key.jks"
ca-certificate-file="/tmp/ews-eap6/ca-cert.jks"/>
</connector>
<virtual-server name="default-host" enable-welcome-root="true">
<alias name="localhost"/>
<alias name="example.com"/>
</virtual-server>
</subsystem>
{code}
Notice that while EAP 6.3.0.DR1 with *jbossweb-7.3.0.Final* uses {{org.apache.coyote.http11}}, even if natives are unpacked in {{modules/system/layers/base/org/jboss/as/web/main/lib/linux-x86_64/libtcnative-1.so}}, because there is {{native="false"}} in the web subsystem configuration, EAP 6.3.0.DR2 with *jbossweb-7.4.0.Beta4* tries to start {{org.apache.coyote.http11.Http11NioProtocol}} despite having {{native="false"}}.
This causes cipher suite errors, because the native implementation doesn't know what to do with it...
* EAP 6.3.0.DR1 with jbossweb-7.3.0.Final passes this test with no exceptions thrown.
* EAP 6.3.0.DR2 with jbossweb-7.4.0.Beta4 causes:
{noformat}
06:18:26,649 ERROR [org.apache.coyote.http11.Http11NioProtocol] (MSC service thread 1-17) JBWEB003043: Error initializing endpoint: java.io.IOException: JBWEB002081: No cipher match
at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:315) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
at org.apache.tomcat.util.net.NioEndpoint.init(NioEndpoint.java:205) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
at org.apache.coyote.http11.Http11NioProtocol.init(Http11NioProtocol.java:113) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
at org.apache.catalina.connector.Connector.init(Connector.java:983) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304) [jboss-as-web-7.4.0.Final-redhat-2.jar:7.4.0.Final-redhat-2]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: java.io.IOException: JBWEB002081: No cipher match
at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.getEnabledCiphers(NioJSSESocketChannelFactory.java:399) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
at org.apache.tomcat.util.net.jsse.NioJSSESocketChannelFactory.init(NioJSSESocketChannelFactory.java:305) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
... 9 more
06:18:26,663 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-39) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
06:18:26,672 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-17) MSC000001: Failed to start service jboss.web.connector.https: org.jboss.msc.service.StartException in service jboss.web.connector.https: JBAS018007: Error starting web connector
at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:362)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final.jar:1.1.5.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
Caused by: LifecycleException: JBWEB000023: Protocol handler initialization failed
at org.apache.catalina.connector.Connector.init(Connector.java:985)
at org.jboss.as.web.WebConnectorService.start(WebConnectorService.java:304)
... 5 more
{noformat}
Any ideas?
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-3073) MBeanServer.createMBean methods that take a classloader don't work
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3073?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-3073:
----------------------------------
Never mind, your fix looks fine
> MBeanServer.createMBean methods that take a classloader don't work
> ------------------------------------------------------------------
>
> Key: WFLY-3073
> URL: https://issues.jboss.org/browse/WFLY-3073
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Affects Versions: 8.0.0.Final
> Reporter: Stuart Douglas
> Assignee: Kabir Khan
> Fix For: 8.0.1.Final
>
>
> The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6.
> These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception.
> This is obviously wrong, as there'd be no point in calling createMBean if it already existed.
> javax.management.InstanceNotFoundException: test:service=Test
> at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253)
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-3051) JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
by Rituraj Sinha (JIRA)
[ https://issues.jboss.org/browse/WFLY-3051?page=com.atlassian.jira.plugin.... ]
Rituraj Sinha commented on WFLY-3051:
-------------------------------------
Hi Darran
can we get some information as how much time it is going to take ...thanks for looking into it...
Thanks
> JMX connection to remote server-instances is not happening in wildfly 8.0.0.Final in domain mode
> ------------------------------------------------------------------------------------------------
>
> Key: WFLY-3051
> URL: https://issues.jboss.org/browse/WFLY-3051
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JMX, Remoting
> Affects Versions: 8.0.0.Final
> Reporter: Rituraj Sinha
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> i have gone through the below link for JMX subsystem for wildfly 8 as
> https://docs.jboss.org/author/display/WFLY8/JMX+subsystem+configuration
>
> but unable to connect to server-instances running remotely ...i have posted my question there as well and pasting it here now ...
> can someone please give us the steps to configure JMX through jconsole...?
> changes done on the domain.xml are the same as stated above
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector use-management-endpoint="false"/>
> </subsystem>
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
> <expose-resolved-model/>
> <expose-expression-model/>
> <remoting-connector use-management-endpoint="false"/>
> </subsystem>
> as per the jboss-as-jmx_1_3.xsd its like
> <xs:attribute name="use-management-endpoint" type="xs:boolean" default="true" use="optional" >
> <xs:annotation>
> <xs:documentation>
> If true then this connector will use the management endpoint, otherwise it will use the
> remoting subsystem endpoint.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> now if we are making it false then it should be using the remoting endpoint ...now remoting subsystem by default uses ApplicatoinRealm
> i have created application-user and password for the same but when i am trying to connect to remote server-instances its not connecting it....
> below is what i am able to connect to
> service:jmx:http-remoting-jmx://remote_hostA:9990 --
> Unknown macro: {host A is where my domain_controller is running}
> how can i access the server-instances running on domain_controller
> Unknown macro: {there are three server_instanaces running on HostA with a port offset of 100 each}
> i am trying to connect with the below url as
> service:jmx:http-remoting-jmx://lremote_hostA:8180
> let me know if something is missing from my side...
> Thanks
--
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
12 years, 4 months
[JBoss JIRA] (WFLY-2581) Provide API for use by ejb-security-interceptors quick start.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2581?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2581:
----------------------------------------
Pull request to also update the quickstarts: -
https://github.com/wildfly/quickstart/pull/20
> Provide API for use by ejb-security-interceptors quick start.
> -------------------------------------------------------------
>
> Key: WFLY-2581
> URL: https://issues.jboss.org/browse/WFLY-2581
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
> • org.jboss.as.domain.management.security.RealmUser.
> • org.jboss.as.security.remoting.RemotingContext.
> • org.jboss.as.controller.security.SubjectUserInfo
> The first problem is the RemotingContext, we use it internally to associate the remoting connection with the thread processing the request, the only reason we really use it is to obtain the identity of the user associated with the connection, we may be better simplifying this down to just associate a simple ConnectionSecurityContext with the thread instead.
> Secondly once we have used the identity associated with the connection we clear the association, this is probably the wrong way round and instead we should be setting something to say we have used the identity.
> The SubjectUserInfo is essentially the ConnectionSecurityContext I mention above, we need a simple representation of this that can be used.
> Finally there is RealmUser, we should also add RealmGroup - these two classes just need to be in their own public module or inherit from something that is.
> As a closing point should these be marked as deprecated? Security services are being re-worked in WildFly and this whole quick start is just an alternative solution to the new 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
12 years, 4 months
[JBoss JIRA] (WFLY-3073) MBeanServer.createMBean methods that take a classloader don't work
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3073?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-3073:
----------------------------------
These should probably pass in the loaderName rather than the name of the mbean to create to findDelegate()?
> MBeanServer.createMBean methods that take a classloader don't work
> ------------------------------------------------------------------
>
> Key: WFLY-3073
> URL: https://issues.jboss.org/browse/WFLY-3073
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JMX
> Affects Versions: 8.0.0.Final
> Reporter: Stuart Douglas
> Assignee: Kabir Khan
> Fix For: 8.0.1.Final
>
>
> The MBeanServer.createMBean methods that take an "ObjectName loaderName" argument are completely broken in EAP 6.
> These methods call findDelegate to make sure there is already an existing MBean registered with the given name passed in for the new MBean, or else it throws an exception.
> This is obviously wrong, as there'd be no point in calling createMBean if it already existed.
> javax.management.InstanceNotFoundException: test:service=Test
> at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1083)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.createMBean(PluggableMBeanServerImpl.java:253)
--
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
12 years, 4 months