[JBoss JIRA] (JBWEB-314) FormAuthenticator duplicates original request GET parameters
by Dominik Pospisil (JIRA)
Dominik Pospisil created JBWEB-314:
--------------------------------------
Summary: FormAuthenticator duplicates original request GET parameters
Key: JBWEB-314
URL: https://issues.jboss.org/browse/JBWEB-314
Project: JBoss Web
Issue Type: Bug
Reporter: Dominik Pospisil
Assignee: Remy Maucherat
The FormAuthenticator duplicates original request GET parameters. This is a regression since rev. 2320.
The FormAuth does saved.addParameter(name, val) which results in parameter value stored twice.
request.getParameter(String name) retutns the original value which is fine
but request.getParameterValues(String name) returns String[] {val,val} incorrectly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (ELY-402) A wrapper KeyStore that can filter by alias
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-402?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse reassigned ELY-402:
------------------------------------
Assignee: Darran Lofthouse
> A wrapper KeyStore that can filter by alias
> -------------------------------------------
>
> Key: ELY-402
> URL: https://issues.jboss.org/browse/ELY-402
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: SSL
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 1.1.0.Beta4
>
>
> A common request is that when a server is configured for SSL the alias to use from the KeyStore can be specified - this can be a little short sighted as a huge advantage of multiple entries in a single KeyStore is that different entries can be used depending on the selected cipher suite.
> A better option may be to add alias filtering so a wrapper KeyStore can still make a number of underlying entries available.
> Alias filtering is better handled at the KeyStore level as the KeyManager should be performing additional checks to ensure the keys and signatures are compatible with the current cipher suite.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-4682) standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4682?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski updated WFLY-4682:
-------------------------------------
Issue Type: Enhancement (was: Bug)
> standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-4682
> URL: https://issues.jboss.org/browse/WFLY-4682
> Project: WildFly
> Issue Type: Enhancement
> Components: Class Loading, MSC
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1
> Reporter: Miroslav Novak
> Assignee: Bartosz Baranowski
> Labels: duplicate
> Attachments: standalone-full.xml
>
>
> Deployment (Servlet, EJB, MDB) which is using Websphere MQ 8 resource adapter to send/receive messages from external Websphere MQ 8 instance is not loading "javax.jms.api" module. Deployment is using JMS api.
> This is change in behaviour against previous versions EAP 6/Widlfly 9.
> There is no error during deploy. Failures occur in the moment when deployment for example servlet is called. Following error is logged in EAP 7.0.0.DR2 log:
> {code}
> 08:57:24,835 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "servlet.war" with deployment "servlet.war"
> 08:57:24,838 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0002: Content removed from location /home/mnovak/projects/eap-tests-wsmq/ibm-mq-testsuite/src/test/config/ibm8/install/jboss-eap-7.0/standalone/data/content/62/931347d12b65c80cd2201372be52f0494e361a/content
> 08:57:25,794 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /CleaningServlet/CleaningServlet: java.lang.NoClassDefFoundError: javax/jms/Message
> at org.jboss.as.test.ibm.mq.servlet.CleaningServlet.doGet(CleaningServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: javax.jms.Message from [Module "deployment.servlet.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 30 more
> {code}
> Websphere MQ resource adapter is rar archive in deployments directory. It's not configured in module. Only way to force loading of "javax.jms.api" for deployment is to add Dependecies: javax.jms.api to MANIFEST.MF or add it to global-modules. This negatively affects usability.
> Can be javax.jms.api loaded for deployment by default for "full" and "full-ha" profile?
> I'm adding standalone-full.xml with configuration for EAP 7.0.0.DR2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-4682) standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-4682?page=com.atlassian.jira.plugin.... ]
Bartosz Baranowski reassigned WFLY-4682:
----------------------------------------
Assignee: Flavia Rainone (was: Bartosz Baranowski)
> standalone-full.xml does not load javax.jms.api for deployment which is using Websphere MQ 8
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-4682
> URL: https://issues.jboss.org/browse/WFLY-4682
> Project: WildFly
> Issue Type: Enhancement
> Components: Class Loading, MSC
> Affects Versions: 9.0.0.CR1, 10.0.0.Alpha1
> Reporter: Miroslav Novak
> Assignee: Flavia Rainone
> Labels: duplicate
> Attachments: standalone-full.xml
>
>
> Deployment (Servlet, EJB, MDB) which is using Websphere MQ 8 resource adapter to send/receive messages from external Websphere MQ 8 instance is not loading "javax.jms.api" module. Deployment is using JMS api.
> This is change in behaviour against previous versions EAP 6/Widlfly 9.
> There is no error during deploy. Failures occur in the moment when deployment for example servlet is called. Following error is logged in EAP 7.0.0.DR2 log:
> {code}
> 08:57:24,835 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0016: Replaced deployment "servlet.war" with deployment "servlet.war"
> 08:57:24,838 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0002: Content removed from location /home/mnovak/projects/eap-tests-wsmq/ibm-mq-testsuite/src/test/config/ibm8/install/jboss-eap-7.0/standalone/data/content/62/931347d12b65c80cd2201372be52f0494e361a/content
> 08:57:25,794 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /CleaningServlet/CleaningServlet: java.lang.NoClassDefFoundError: javax/jms/Message
> at org.jboss.as.test.ibm.mq.servlet.CleaningServlet.doGet(CleaningServlet.java:50)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: javax.jms.Message from [Module "deployment.servlet.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 30 more
> {code}
> Websphere MQ resource adapter is rar archive in deployments directory. It's not configured in module. Only way to force loading of "javax.jms.api" for deployment is to add Dependecies: javax.jms.api to MANIFEST.MF or add it to global-modules. This negatively affects usability.
> Can be javax.jms.api loaded for deployment by default for "full" and "full-ha" profile?
> I'm adding standalone-full.xml with configuration for EAP 7.0.0.DR2.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-5081) WebSphere MQ 8 RA - [TCK] - Defining connection factory by @JMSConnectionFactoryDefinition annotation or in deployment descriptor fails
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5081?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil closed WFLY-5081.
-----------------------------
PR merged in master branch
> WebSphere MQ 8 RA - [TCK] - Defining connection factory by @JMSConnectionFactoryDefinition annotation or in deployment descriptor fails
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5081
> URL: https://issues.jboss.org/browse/WFLY-5081
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Beta1
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 10.1.0.Final
>
>
> If WebSphere MQ 8 resource adapter is configured as default resource adapter for MDB in ejb subsystem and MDB is trying to deploy its connection factory like:
> {code}
> @JMSConnectionFactoryDefinition(
> description="Define TopicConnectionFactory AppClientMyTestTopicConnectionFactory",
> interfaceName="javax.jms.TopicConnectionFactory",
> name="java:module/AppClientMyTestTopicConnectionFactory",
> user = "j2ee",
> password = "j2ee",
> )
> {code}
> then deployment fails with:
> {code}
> 11:18:37,471 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 2) WFLYDR0001: Content added at location /home/mnovak/mnovak_home/tmp/tck7/work/jboss-eap-7.0/standalone/data/content/1d/4fbecb4dd1e3a9c03b791cd64c21cd6b7f49de/content
> 11:18:37,475 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0027: Starting deployment of "mdb-1.0-SNAPSHOT.jar" (runtime-name: "mdb-1.0-SNAPSHOT.jar")
> 11:18:37,499 INFO [org.jboss.as.ejb3] (MSC service thread 1-2) WFLYEJB0042: Started message driven bean 'SampleMdb' with 'wmq.jmsra' resource adapter
> 11:18:37,501 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "mdb-1.0-SNAPSHOT.jar")]) - failure description: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.app.\"mdb-1.0-SNAPSHOT\".AppClientMyTestQueueConnectionFactory is missing [jboss.connection-factory.reference-factory.jboss.naming.context.java.app.\"mdb-1.0-SNAPSHOT\".AppClientMyTestQueueConnectionFactory]"]}
> 11:18:37,616 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "mdb-1.0-SNAPSHOT.jar" (runtime-name : "mdb-1.0-SNAPSHOT.jar")
> 11:18:37,616 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report
> WFLYCTL0185: Newly corrected services:
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".component.SampleMdb.CREATE (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".component.SampleMdb.JndiBindingsService (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".component.SampleMdb.START (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".component.SampleMdb.VIEW.SampleMdb.MESSAGE_ENDPOINT (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".component.SampleMdb.ejb.non-functional-timerservice (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".jndiDependencyService (new available)
> service jboss.deployment.unit."mdb-1.0-SNAPSHOT.jar".moduleDeploymentRuntimeInformation (new available)
> service jboss.naming.context.java.app."mdb-1.0-SNAPSHOT".AppClientMyTestQueueConnectionFactory (new available)
> service jboss.naming.context.java.app."mdb-1.0-SNAPSHOT".env (new available)
> service jboss.naming.context.java.comp."mdb-1.0-SNAPSHOT"."mdb-1.0-SNAPSHOT".SampleMdb (new available)
> service jboss.naming.context.java.comp."mdb-1.0-SNAPSHOT"."mdb-1.0-SNAPSHOT".SampleMdb.TransactionSynchronizationRegistry (new available)
> service jboss.naming.context.java.comp."mdb-1.0-SNAPSHOT"."mdb-1.0-SNAPSHOT".SampleMdb.UserTransaction (new available)
> service jboss.naming.context.java.module."mdb-1.0-SNAPSHOT"."mdb-1.0-SNAPSHOT".env (new available)
> {code}
> Customer impact:
> Any deployment which needs to define its connection factory in deployment will fail. Customer cannot use @JMSConnectionFactoryDefinition to deploy connection factory.
> Debugging showed that deployment of connection factory defined in @JMSConnectionFactoryDefinition is using messaging activemq extension integration. WebSphereMQ's managed connection factory cannot be added as pooled-connection-factory to messaging-activemq subsystem.
> We need to provide a way 3rd party JMS managed connection factory will be created and registered to JNDI.
> Failing TCK tests failing because of this issue:
> {code}
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/annotations/Client.j...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> [javatest.batch] FAILED........com/sun/ts/tests/jms/ee20/resourcedefs/descriptor/Client.ja...
> {cdde}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFCORE-102) Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-102?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-102:
------------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1299102|https://bugzilla.redhat.com/show_bug.cgi?id=1299102] from ASSIGNED to NEW
> Remove the need for OSH authors to deal with ServiceVerificationHandler or removal of installed services in rollback
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-102
> URL: https://issues.jboss.org/browse/WFCORE-102
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha9
>
>
> The various base classes OSH authors use to create handlers force the author to deal with ServiceVerificationHandler and, during rollback, with removing any services the OSH added. This task is to have the OperationContext handle these things transparently, removing the need for authors to do so.
> To preserve compatibility, the various API methods authors may have overridden that expose the SVH and the list of added ServiceControllers will be retained (but deprecated), but the SVH and the list of handlers won't be used. The API javadoc will encourage use of method variants that don't use these parameters.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-5850) Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-5850?page=com.atlassian.jira.plugin.... ]
Ladislav Thon commented on WFLY-5850:
-------------------------------------
[~brian.stansberry] I think I understand what you're saying, but it seemed a bit counterintuitive to me at first. So I think we must document this clearly. Here's my take:
bq. Using the {{:migrate}} mgmt operations, you're able to move your EAP 6 configuration files to WildFly 10. Still, after the migration, the configuration files will reflect the original EAP 6 configuration (e.g. {{remoting}} protocol instead of WildFly's new {{http-remoting}}, port numbers, etc.) and will not contain new EE7 subsystems nor new WildFly features (e.g. batch processing, clustered singleton deployments or graceful shutdown). To bring your configuration files fully up to date, while keeping the essential EAP 6 configuration, you must use the WildFly Server Migration tool.
Would something like that work for you? (I think that we should use a similar text in EAP 7 Migration Guide, for which I will create a separate JIRA once we get an agreement here.)
> Can't deploy an EJB to a WildFly 10 server migrated from EAP 6.4
> ----------------------------------------------------------------
>
> Key: WFLY-5850
> URL: https://issues.jboss.org/browse/WFLY-5850
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ladislav Thon
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.1.0.Final
>
>
> I just tried to migrate a {{standalone.xml}} server from clean EAP 6.4.0 to WildFly 10.0.0.CR4 and then deploy the {{server-side}} part of the {{ejb-remote}} quickstart:
> {code}
> git clone git@github.com:jboss-developer/jboss-eap-quickstarts.git
> cd jboss-eap-quickstarts/
> git checkout -b 6.4.x origin/6.4.x
> cd ejb-remote/server-side/
> mvn clean package -s ../../settings.xml
> cd target
> unzip .../jboss-eap-6.4.0.zip
> unzip .../wildfly-10.0.0.CR4.zip
> cp jboss-eap-6.4/standalone/configuration/standalone.xml wildfly-10.0.0.CR4/standalone/configuration/test.xml
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml --admin-only
> # on a separate console
> ./wildfly-10.0.0.CR4/bin/jboss-cli.sh -c --controller=localhost:9999
> /subsystem=threads:remove
> /extension=org.jboss.as.threads:remove
> /subsystem=web:migrate
> shutdown
> # on the original console
> cp jboss-ejb-remote-server-side.jar wildfly-10.0.0.CR4/standalone/deployments/
> ./wildfly-10.0.0.CR4/bin/standalone.sh -c test.xml
> {code}
> What I get is this horrible stack trace:
> {code}
> 15:35:50,913 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-ejb-remote-server-side.jar".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "jboss-ejb-remote-server-side.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.
> at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:271)
> at org.hibernate.validator.internal.cdi.ValidationExtension.<init>(ValidationExtension.java:109)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.8.0_66]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) [rt.jar:1.8.0_66]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.8.0_66]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422) [rt.jar:1.8.0_66]
> at java.lang.Class.newInstance(Class.java:442) [rt.jar:1.8.0_66]
> at org.jboss.as.weld.deployment.WeldPortableExtensions.tryRegisterExtension(WeldPortableExtensions.java:53)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:121)
> at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147) [wildfly-server-2.0.0.CR8.jar:2.0.0.CR8]
> ... 5 more
> 15:35:50,921 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "jboss-ejb-remote-server-side.jar")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jboss-ejb-remote-server-side.jar\".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"jboss-ejb-remote-server-side.jar\"
> Caused by: javax.validation.ValidationException: Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath."}}
> {code}
> When I deploy the same JAR to a clean install of WildFly 10.0.0.CR4, it works just fine. This suggests that something (probably the EJB subsystem?) doesn't correctly parse/serialize the legacy configuration. Or something like that.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (SECURITY-921) SPNEGO authentication fails on Windows-KDC
by Kai Winter (JIRA)
[ https://issues.jboss.org/browse/SECURITY-921?page=com.atlassian.jira.plug... ]
Kai Winter commented on SECURITY-921:
-------------------------------------
I've sent a pull request: https://github.com/wildfly-security/jboss-negotiation/pull/28
I followed the suggested implementation in this issue. Tested and working.
> SPNEGO authentication fails on Windows-KDC
> ------------------------------------------
>
> Key: SECURITY-921
> URL: https://issues.jboss.org/browse/SECURITY-921
> Project: PicketBox
> Issue Type: Bug
> Components: Negotiation
> Affects Versions: Negotiation_3_0_0_CR1
> Environment: *
> Reporter: Harald Krause
> Assignee: Darran Lofthouse
> Labels: web_security
>
> Inside the "SPNEGOLoginModule" (3.0.0.CR2-SNAPSHOT) the run()-Method of inner class "AcceptSecContext" checks for existence of Kerberos-oid within the SPNEGO-Token. But it checks solely the first element of the mechanism-list:
> {code:java}
> if (mechList.get(0).equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> }
> else
> {
> boolean kerberosSupported = false;
> ...
> {code}
> But SPNEGO-Token from Windows-KDC (2008 R2) supports four types of authentication (oids):
> * oid: 1.2.840.48018.1.2.2 (Windows Kerberos V5)
> * oid: 1.2.840.113554.1.2.2 (Kerberos V5 - we are looking for)
> * oid: 1.3.6.1.4.1.311.2.2.30 NegoEx
> * oid: 1.3.6.1.4.1.311.2.2.10 NTLM
> So Kerberos-check within run()-method should iterate the mechList until it founds Kerberos-V5-oid:
> {code:java}
> for (Oid oid : mechList)
> {
> if (oid.equals(kerberos))
> {
> gssToken = negTokenInit.getMechToken();
> break;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (WFLY-2655) Show warning for JDBC drivers as modules with no driver
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2655?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2655:
-----------------------------------------------
James Livingston <jlivings(a)redhat.com> changed the Status of [bug 1043339|https://bugzilla.redhat.com/show_bug.cgi?id=1043339] from ASSIGNED to CLOSED
> Show warning for JDBC drivers as modules with no driver
> -------------------------------------------------------
>
> Key: WFLY-2655
> URL: https://issues.jboss.org/browse/WFLY-2655
> Project: WildFly
> Issue Type: Enhancement
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: James Livingston
> Assignee: Jeff Zhang
> Fix For: 8.1.0.CR1, 8.1.0.Final
>
>
> If a <driver> if configured with no <driver-class>, it will attempt to locate the driver(s) via the service loader which should find all JDBC4-compliant drivers.
> When you install a non JDBC4-complicant driver as a module and no <driver-class>, the driver will not be installed. That is expected but emitting a warning that no-drivers could be found in the module would be useful to help users troubleshoot the problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months