[JBoss JIRA] (WFLY-1411) UT005013 at the end of an Arquillian test
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1411?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1411:
------------------------------------------
Confirmed.
> UT005013 at the end of an Arquillian test
> -----------------------------------------
>
> Key: WFLY-1411
> URL: https://issues.jboss.org/browse/WFLY-1411
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> I'm using an Alpha 2 snapshot of WildFly. When an Arquillian test ends I'm getting the following stacktrace:
> ...
> 20:07:12,101 INFO [org.jboss.as.server] JBAS018558: Undeployed "shop2.war" (runtime-name: "shop2.war")
> 20:07:12,131 ERROR [io.undertow.request.io] UT005013: An IOException occurred: java.io.IOException: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
> at sun.nio.ch.SocketDispatcher.read0(Native Method) [rt.jar:1.7.0_21]
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) [rt.jar:1.7.0_21]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225) [rt.jar:1.7.0_21]
> at sun.nio.ch.IOUtil.read(IOUtil.java:193) [rt.jar:1.7.0_21]
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359) [rt.jar:1.7.0_21]
> at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:262) [xnio-nio-3.1.0.CR3.jar:3.1.0.CR3]
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> at io.undertow.server.HttpReadListener.handleEvent(HttpReadListener.java:83)
> at io.undertow.server.HttpReadListener.handleEvent(HttpReadListener.java:43)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85) [xnio-nio-3.1.0.CR3.jar:3.1.0.CR3]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:528) [xnio-nio-3.1.0.CR3.jar:3.1.0.CR3]
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-1440) How to configure ssl with mod_cluster and JBoss 7.1.1
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1440?page=com.atlassian.jira.plugin.... ]
Steven Hawkins moved TEIID-2523 to WFLY-1440:
---------------------------------------------
Project: WildFly (was: Teiid)
Key: WFLY-1440 (was: TEIID-2523)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: (was: 7.1.1)
> How to configure ssl with mod_cluster and JBoss 7.1.1
> -----------------------------------------------------
>
> Key: WFLY-1440
> URL: https://issues.jboss.org/browse/WFLY-1440
> Project: WildFly
> Issue Type: Feature Request
> Environment: - One LPAR with AIX 7.1, mod_cluster 1.1.3, http 2.2.14
> - Two LPAR with AIX 7.1, JBoss 7.1.1. Final
> Reporter: Jose Giner
> Assignee: Steven Hawkins
>
> Hi,
> We configure three LPAR with AIX7.1:
> - One LPAR for Web with mod_cluster 1.1.3 and http 2.2.14
> - Two LPAR for JBoss 7.1.1 Final.
> Now we want to securize the Web LPAR.
> 1.- We create a local certificate on Web LPAR:
> openssl genrsa -des3 -out server.key 1024
> openssl req -new -key server.key -out server.csr
> openssl req -new -key server.key -out server.csr
> openssl x509 -req -days 730 -in server.csr -signkey server.key -out server.crt
> 2.- We comment the line "Include conf/extra/httpd-vhosts.conf" on httpd.conf
> 3.- We uncommnet the line "Include conf/extra/httpd-ssl.conf" on httpd.conf
> 4.- We copy the content of conf/extra/httpd-vhosts.conf at the bottom of conf/extra/httpd-ssl.conf and change the port 10001 by 443 and add SSL configuration:
> </VirtualHost>
> Listen 192.168.34.19:443
> MemManagerFile /var/cache/httpd
> <VirtualHost 192.168.34.19:443>
> SSLEngine on
> SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
> SSLCertificateFile pki/server.crt
> SSLCertificateKeyFile pki/server.key
> SSLVerifyClient require
> SSLVerifyDepth 10
> <Directory />
> Order deny,allow
> Allow from all
> </Directory>
> KeepAliveTimeout 60
> MaxKeepAliveRequests 0
> ManagerBalancerName other-server-group
> AdvertiseFrequency 5
> #This directive allows you to view mod_cluster status at URL http://192.168.34.19:10001/mod_cluster-manager
> <Location /mod_cluster-manager>
> SetHandler mod_cluster-manager
> Order deny,allow
> Allow from all
> </Location>
> </VirtualHost>
> but we cannot connect using https://.....
> Anything wrong? We must configure something in JBoss?
> Regards,
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-1368) NumberFormatException in UndertowDeploymentInfoService when war is deployed
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1368?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1368:
------------------------------------------
Confirmed.
> NumberFormatException in UndertowDeploymentInfoService when war is deployed
> ---------------------------------------------------------------------------
>
> Key: WFLY-1368
> URL: https://issues.jboss.org/browse/WFLY-1368
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
> Attachments: web.xml
>
>
> I compiled WildFly on a Windows box (Win7, x64, JDK 1.7.0_21 32bit). Starting the WildFly appserver without any app works fine.
> Next I tried to deploy a war. However, I get the stacktrace below caused by a NumberFormatException.
> 14:59:29,806 ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.undertow.deployment.default-host./shop2.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-host./shop2.UndertowDeploymentInfoService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1930) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: java.lang.NumberFormatException: null
> at java.lang.Integer.parseInt(Integer.java:454) [rt.jar:1.7.0_21]
> at java.lang.Integer.parseInt(Integer.java:527) [rt.jar:1.7.0_21]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:513)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:200)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> ... 3 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
13 years, 1 month
[JBoss JIRA] (WFLY-1440) How to configure ssl with mod_cluster and JBoss 7.1.1
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-1440?page=com.atlassian.jira.plugin.... ]
Steven Hawkins updated WFLY-1440:
---------------------------------
Assignee: (was: Steven Hawkins)
> How to configure ssl with mod_cluster and JBoss 7.1.1
> -----------------------------------------------------
>
> Key: WFLY-1440
> URL: https://issues.jboss.org/browse/WFLY-1440
> Project: WildFly
> Issue Type: Feature Request
> Environment: - One LPAR with AIX 7.1, mod_cluster 1.1.3, http 2.2.14
> - Two LPAR with AIX 7.1, JBoss 7.1.1. Final
> Reporter: Jose Giner
>
> Hi,
> We configure three LPAR with AIX7.1:
> - One LPAR for Web with mod_cluster 1.1.3 and http 2.2.14
> - Two LPAR for JBoss 7.1.1 Final.
> Now we want to securize the Web LPAR.
> 1.- We create a local certificate on Web LPAR:
> openssl genrsa -des3 -out server.key 1024
> openssl req -new -key server.key -out server.csr
> openssl req -new -key server.key -out server.csr
> openssl x509 -req -days 730 -in server.csr -signkey server.key -out server.crt
> 2.- We comment the line "Include conf/extra/httpd-vhosts.conf" on httpd.conf
> 3.- We uncommnet the line "Include conf/extra/httpd-ssl.conf" on httpd.conf
> 4.- We copy the content of conf/extra/httpd-vhosts.conf at the bottom of conf/extra/httpd-ssl.conf and change the port 10001 by 443 and add SSL configuration:
> </VirtualHost>
> Listen 192.168.34.19:443
> MemManagerFile /var/cache/httpd
> <VirtualHost 192.168.34.19:443>
> SSLEngine on
> SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
> SSLCertificateFile pki/server.crt
> SSLCertificateKeyFile pki/server.key
> SSLVerifyClient require
> SSLVerifyDepth 10
> <Directory />
> Order deny,allow
> Allow from all
> </Directory>
> KeepAliveTimeout 60
> MaxKeepAliveRequests 0
> ManagerBalancerName other-server-group
> AdvertiseFrequency 5
> #This directive allows you to view mod_cluster status at URL http://192.168.34.19:10001/mod_cluster-manager
> <Location /mod_cluster-manager>
> SetHandler mod_cluster-manager
> Order deny,allow
> Allow from all
> </Location>
> </VirtualHost>
> but we cannot connect using https://.....
> Anything wrong? We must configure something in JBoss?
> Regards,
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-1414) Undertow suppresses JAX-RS error message
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/WFLY-1414?page=com.atlassian.jira.plugin.... ]
Juergen Zimmermann commented on WFLY-1414:
------------------------------------------
Confirmed.
> Undertow suppresses JAX-RS error message
> ----------------------------------------
>
> Key: WFLY-1414
> URL: https://issues.jboss.org/browse/WFLY-1414
> Project: WildFly
> Issue Type: Bug
> Components: REST, Web (Undertow)
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> I'm using a snapshot of WildFly 8.0.0.Alpha2 containing Undertow 1.0.0.Alpha17.
> My RESTful Web Service in a war is using an ExceptionMapper (see below) which converts an exception into a 404 error code and also an error message. Now I try to submit a GET request resulting in an exception to be mapped.
> I get the 404 error code, but NOT the error message. Instead I'm getting the contents of the error page which is declared in web.xml for a 404 error. In EAP 6.1.Beta I'm getting the error message produced by the exception mapper.
> The exception mapper class:
> @Provider
> @ApplicationScoped
> public class NotFoundExceptionMapper implements ExceptionMapper<NotFoundException> {
> @Override
> public Response toResponse(NotFoundException e) {
> final String msg = e.getMessage();
> final Response response = Response.status(NOT_FOUND)
> .type(TEXT_PLAIN)
> .entity(msg)
> .build();
> return response;
> }
> }
--
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
13 years, 1 month
[JBoss JIRA] (WFLY-794) javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-794?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-794:
----------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 959565|https://bugzilla.redhat.com/show_bug.cgi?id=959565] from NEW to CLOSED
> javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown when creating MBeanServerConnection
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-794
> URL: https://issues.jboss.org/browse/WFLY-794
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Reporter: Alex Corvino
> Assignee: Bartosz Baranowski
> Attachments: jmx-test.jar, JmxClient.java, JMXConnectionBean.java, JmxServer.java
>
>
> When trying to create a MBeanServerConnection to a NON-JBoss application from within an EJB a "javax.naming.NameNotFoundException" is thrown.
> Steps to reproduce:
> Set up a stand-alone application that exposes an MBean. (ActiveMQ will work in this case.)
> Modify the attached JMXConnectionBean.java to connect to the ActiveMQ instance.
> Deploy the bean. A NameNotFoundException will be thrown.
> I've seen this behavior in 7.1.1.Final, 7.1.2.Final (EAP), 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final).
> Note that this behavior is NOT seen when connecting to another JBoss server.
> Full stack trace:
> {code}
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:340) [:1.6.0_26]
> at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) [:1.6.0_26]
> at com.example.JMXConnectionBean.init(JMXConnectionBean.java:28)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_26]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_26]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_26]
> at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_26]
> at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:70)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:44)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor$CustomSessionInvocationContext.proceed(SessionInvocationContextInterceptor.java:126)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:211)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:313)
> at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56)
> at org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:42)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ejb3.component.session.SessionInvocationContextInterceptor.processInvocation(SessionInvocationContextInterceptor.java:71)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)
> ... 9 more
> Caused by: javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi -- service jboss.naming.context.java.rmi:."127.0.0.1:1090".jmxrmi
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:87)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:173)
> at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:47)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:209)
> at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1888) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1858) [:1.6.0_26]
> at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) [:1.6.0_26]
> ... 37 more
> {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
13 years, 1 month
[JBoss JIRA] (WFLY-430) Update the whoami operation to also show the authentication mechanism when called with verbose=true
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-430?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on WFLY-430:
---------------------------------------
I have pulled this into WildFly 8 schedule as information from this operation could be very useful to access control.
When working on access control it does sound like a users roles may be loaded in the context of the operation they are performing, this operation will be very useful to double check which roles were assigned at specific locations.
> Update the whoami operation to also show the authentication mechanism when called with verbose=true
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-430
> URL: https://issues.jboss.org/browse/WFLY-430
> Project: WildFly
> Issue Type: Task
> Components: CLI, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.Alpha2
>
>
> I need to review if this is feasible but there are a number of reports coming in where end users believe their server is not secured because our local / silent mechanism is working so quietly.
--
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
13 years, 1 month