[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-1598:
--------------------------------------
Summary: Out of the box SSL - or shortly after.
Key: WFLY-1598
URL: https://issues.jboss.org/browse/WFLY-1598
Project: WildFly
Issue Type: Feature Request
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Critical
Fix For: 9.0.0.CR1
There are various reasons that we do not support SSL/TLS out of the box e.g.
- If we ship a default keystore then everyone has access to the private key.
- Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
This issue is to explorer other options to encourage their use and make it easier to configure.
As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?
--
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-1597) Re-Review TLS/SSL where web sockets are in use.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-1597:
--------------------------------------
Summary: Re-Review TLS/SSL where web sockets are in use.
Key: WFLY-1597
URL: https://issues.jboss.org/browse/WFLY-1597
Project: WildFly
Issue Type: Feature Request
Components: Domain Management, Remoting, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Critical
Fix For: 8.0.0.Alpha3
Need to double check the behaviour here, the wrapping of Remoting so far it leaving the Remoting specific messages as-is - need to verify we are not double encrypting the connection and also the Client Cert based authentication requirements on that connection.
--
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-924) All classes that implement AsyncListener are treated as components causing JBAS011006
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-924?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on WFLY-924:
-----------------------------------
The servlet spec states (3.0 spec, section 15.5, table 15-1) that AsyncListener(s) are eligible for EE resource injection and other annotation based services. So they are expected to be treated as container managed components.
Unlike most other container managed components, implementations of AsyncListener interface can be dynamically registered by the user application, through the use of AsyncContext.createListener(className) API. Such created listeners are expected to be processed by the container for EE resource injection and other such services. This effectively means that the container has to have knowledge of such "possible" AsyncListener candidates which will might be registered by the user applications, so that the container can setup necessary dependencies for those potential AsyncListener(s). The AS7/WildFly container scans the application classpath for the presence of such AsyncListener(s) so that it can do the necessary dependency setup. Of course, the server can't be sure that all/any of these AsyncListener(s) will be registered by the user application, later on. So it considers such AsyncListener(s) as optional components so that failing to construct them will *not* fail the deployment, but instead will log a message that such a optional component construction has failed (notice the log message, it does use the words "Not installing optional component...."). The log message rightly contains the explanation as to why this optional component failed.
If users don't care about such optional components and want to hide this message then perhaps a better way to deal with this is to disable logging for that specific message. (I don't know if JBoss logging allows it, but perhaps the logging can be configured to set log messages with id JBAS011006 to be turned off). If that isn't possible/desired, then an enhancement would be to log the failure of optional components (i.e. the JBAS011006 message) to be at DEBUG level. I would prefer dealing with this at the logging configuration instead of at the code level.
> All classes that implement AsyncListener are treated as components causing JBAS011006
> -------------------------------------------------------------------------------------
>
> Key: WFLY-924
> URL: https://issues.jboss.org/browse/WFLY-924
> Project: WildFly
> Issue Type: Bug
> Environment: JBoss EAP 6.0 GA, web services subsystem removed, war deployed containing Metro or CXF web services implementation
> Reporter: Brad Maxwell
> Assignee: Remy Maucherat
>
> It tries to create this class if CXF is packaged in the war: org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
> And this stack is logged as a warning:
> 11:08:40,879 INFO [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.test.war:main" from Service Module Loader
> 11:08:40,905 WARN [org.jboss.as.ee] (MSC service thread 1-6) JBAS011006: Not installing optional component org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
> at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> If Metro is packaged in the war, it tries to load com.sun.xml.ws.transport.http.servlet.WSAsyncListener and logs a warning with this stack:
> 16:48:57,302 WARN [org.jboss.as.ee] (MSC service thread 1-1) JBAS011006: Not installing optional component com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1
> at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
--
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-924) All classes that implement AsyncListener are treated as components causing JBAS011006
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-924?page=com.atlassian.jira.plugin.s... ]
jaikiran pai edited comment on WFLY-924 at 6/27/13 5:40 AM:
------------------------------------------------------------
The servlet spec states (3.0 spec, section 15.5, table 15-1) that AsyncListener(s) are eligible for EE resource injection and other annotation based services. So they are expected to be treated as container managed components.
Unlike most other container managed components, implementations of AsyncListener interface can be dynamically registered by the user application, through the use of AsyncContext.createListener(className) API. Such created listeners are expected to be processed by the container for EE resource injection and other such services. This effectively means that the container has to have knowledge of such "possible" AsyncListener candidates which will might be registered by the user applications, so that the container can setup necessary dependencies for those potential AsyncListener(s). The AS7/WildFly container scans the application classpath for the presence of such AsyncListener(s) so that it can do the necessary dependency setup. Of course, the server can't be sure that all/any of these AsyncListener(s) will be registered by the user application, later on. So it considers such AsyncListener(s) as optional components so that failing to construct them will *not* fail the deployment, but instead will log a message that such a optional component construction has failed (notice the log message, it does use the words "Not installing optional component...."). The log message rightly contains the explanation as to why this optional component failed.
If users don't care about such optional components and want to hide this message then perhaps a better way to deal with this is to disable logging for that specific message. I don't know if JBoss logging allows it, but perhaps the logging can be configured to set log messages with id JBAS011006 to be turned off. If that isn't possible/desired, then an enhancement would be to log the failure of optional components (i.e. the JBAS011006 message) to be at DEBUG level. I would prefer dealing with this at the logging configuration instead of at the code level.
was (Author: jaikiran):
The servlet spec states (3.0 spec, section 15.5, table 15-1) that AsyncListener(s) are eligible for EE resource injection and other annotation based services. So they are expected to be treated as container managed components.
Unlike most other container managed components, implementations of AsyncListener interface can be dynamically registered by the user application, through the use of AsyncContext.createListener(className) API. Such created listeners are expected to be processed by the container for EE resource injection and other such services. This effectively means that the container has to have knowledge of such "possible" AsyncListener candidates which will might be registered by the user applications, so that the container can setup necessary dependencies for those potential AsyncListener(s). The AS7/WildFly container scans the application classpath for the presence of such AsyncListener(s) so that it can do the necessary dependency setup. Of course, the server can't be sure that all/any of these AsyncListener(s) will be registered by the user application, later on. So it considers such AsyncListener(s) as optional components so that failing to construct them will *not* fail the deployment, but instead will log a message that such a optional component construction has failed (notice the log message, it does use the words "Not installing optional component...."). The log message rightly contains the explanation as to why this optional component failed.
If users don't care about such optional components and want to hide this message then perhaps a better way to deal with this is to disable logging for that specific message. (I don't know if JBoss logging allows it, but perhaps the logging can be configured to set log messages with id JBAS011006 to be turned off). If that isn't possible/desired, then an enhancement would be to log the failure of optional components (i.e. the JBAS011006 message) to be at DEBUG level. I would prefer dealing with this at the logging configuration instead of at the code level.
> All classes that implement AsyncListener are treated as components causing JBAS011006
> -------------------------------------------------------------------------------------
>
> Key: WFLY-924
> URL: https://issues.jboss.org/browse/WFLY-924
> Project: WildFly
> Issue Type: Bug
> Environment: JBoss EAP 6.0 GA, web services subsystem removed, war deployed containing Metro or CXF web services implementation
> Reporter: Brad Maxwell
> Assignee: Remy Maucherat
>
> It tries to create this class if CXF is packaged in the war: org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
> And this stack is logged as a warning:
> 11:08:40,879 INFO [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.test.war:main" from Service Module Loader
> 11:08:40,905 WARN [org.jboss.as.ee] (MSC service thread 1-6) JBAS011006: Not installing optional component org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
> at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> If Metro is packaged in the war, it tries to load com.sun.xml.ws.transport.http.servlet.WSAsyncListener and logs a warning with this stack:
> 16:48:57,302 WARN [org.jboss.as.ee] (MSC service thread 1-1) JBAS011006: Not installing optional component com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1
> at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
--
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-1586) java.lang.NoClassDefFoundError: Could not initialize class com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-1586?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf updated WFLY-1586:
--------------------------------
Description:
With the latest update of OpenJDK to 1.7.0.25-2.3.10.3 there is regression w.r.t. WebServices.
Failing tests:
{noformat}
org.jboss.as.test.integration.ws.ejb.ContextHandlerEndpointTestCase
org.jboss.as.test.integration.ws.injection.ejb.basic.EjbEndpointInsideWarTestCase
org.jboss.as.test.integration.ws.injection.ejb.basic.InjectionTestCase
org.jboss.as.test.integration.ws.wsa.TestNoAddressingTestCase
org.jboss.as.test.integration.ws.wsa.TestOptionalAddressingTestCase
org.jboss.as.test.integration.ws.wsa.TestRequiredAddressingTestCase
org.jboss.as.test.integration.ws.wsse.sign.EJBSignTestCase
org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptMultipleClientsTestCase
org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptTestCase
org.jboss.as.test.integration.ws.wsse.signencrypt.SignEncryptMultipleClientsTestCase
org.jboss.as.test.integration.ws.wsse.signencrypt.SignEncryptTestCase
org.jboss.as.test.integration.ws.wsse.sign.SignTestCase
org.jboss.as.test.xts.simple.wsat.client.WSATTestCase
org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase
org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase
{noformat}
was:With the latest update of OpenJDK to 1.7.0.25-2.3.10.3 there is regression w.r.t. WebServices.
> java.lang.NoClassDefFoundError: Could not initialize class com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1586
> URL: https://issues.jboss.org/browse/WFLY-1586
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.0.0.Alpha2
> Environment: java version "1.7.0_25"
> OpenJDK Runtime Environment (fedora-2.3.10.3.fc17-x86_64)
> OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
> java-1.7.0-openjdk-1.7.0.25-2.3.10.3.fc17.x86_64
> Reporter: Carlo de Wolf
> Assignee: Alessio Soldano
> Priority: Blocker
> Attachments: org.jboss.as.test.xts.simple.wsat.client.WSATTestCase.txt
>
>
> With the latest update of OpenJDK to 1.7.0.25-2.3.10.3 there is regression w.r.t. WebServices.
> Failing tests:
> {noformat}
> org.jboss.as.test.integration.ws.ejb.ContextHandlerEndpointTestCase
> org.jboss.as.test.integration.ws.injection.ejb.basic.EjbEndpointInsideWarTestCase
> org.jboss.as.test.integration.ws.injection.ejb.basic.InjectionTestCase
> org.jboss.as.test.integration.ws.wsa.TestNoAddressingTestCase
> org.jboss.as.test.integration.ws.wsa.TestOptionalAddressingTestCase
> org.jboss.as.test.integration.ws.wsa.TestRequiredAddressingTestCase
> org.jboss.as.test.integration.ws.wsse.sign.EJBSignTestCase
> org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptMultipleClientsTestCase
> org.jboss.as.test.integration.ws.wsse.signencrypt.EJBSignEncryptTestCase
> org.jboss.as.test.integration.ws.wsse.signencrypt.SignEncryptMultipleClientsTestCase
> org.jboss.as.test.integration.ws.wsse.signencrypt.SignEncryptTestCase
> org.jboss.as.test.integration.ws.wsse.sign.SignTestCase
> org.jboss.as.test.xts.simple.wsat.client.WSATTestCase
> org.jboss.as.test.xts.simple.wsba.coordinatorcompletion.client.WSBACoordinatorCompletionTestCase
> org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase
> {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
12 years, 4 months