November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2354) Webservice13 tck failures introduced by ejb3 and security change

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2354?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-2354: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/5332 (was: https://github.com/wildfly/wildfly/pull/5324) > Webservice13 tck failures introduced by ejb3 and security change > ----------------------------------------------------------------- > > Key: WFLY-2354 > URL: https://issues.jboss.org/browse/WFLY-2354 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Affects Versions: 8.0.0.Beta1 > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > > There 2 tck regression failures under webserivice13 directory in EAP 6.2.0.ER6. > IT turns out the change[2] introduced this two failures: > [1]https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/TCK6-EA... > [2][2]https://github.com/jbossas/jboss-eap/commit/72d5cd3f96540519a9747579... > EAP 6.2.0.ER6 sever error message: > ------------------------------------------------------------------------------ > 18:32:00,338 ERROR [org.jboss.as.ejb3.invocation] (http-myserver.com/127.0.0.1:8080-1) JBAS014134: EJB Invocation failed on component WSEjbSingletonTest for method public java.lang.String com.sun.ts.tests.webservices13.ejb.annotations.WSEjbSingletonTest.HelloBean.bye(java.lang.String): javax.ejb.EJBException: java.lang.IllegalStateException: JBAS014485: EJB WSEjbSingletonTest is enabled for security but doesn't have a security domain set > at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:189) [jboss-as-ejb3-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT] -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2497) CLONE - Admin Console does not handle resource adapter address properly

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-2497: -------------------------------------- Summary: CLONE - Admin Console does not handle resource adapter address properly Key: WFLY-2497 URL: https://issues.jboss.org/browse/WFLY-2497 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 8.0.0.Alpha1 Reporter: Bartosz Baranowski Assignee: Bartosz Baranowski Fix For: 8.0.0.CR1 console seems to handle RA entities in a a bad way. Not sure if this is by design and I am the one missing something. In case of anonymous declaration( as per JCA specs ? ): <resource-adapters> <resource-adapter> <archive>test</archive> <transaction-support>NoTransaction</transaction-support> </resource-adapter> </resource-adapters> Name of adapter( in model ) is set to to "test" - archive name. However if there are more adapters, model names become: /subsystem=resource-adapters/resource-adapter=test /subsystem=resource-adapters/resource-adapter=test->1 /subsystem=resource-adapters/resource-adapter=test->2 ... /subsystem=resource-adapters/resource-adapter=test->n++ Now, there is another trick. AS supports custom "ID": <resource-adapters> <resource-adapter id="XXX"> <archive>test</archive> <transaction-support>NoTransaction</transaction-support> </resource-adapter> </resource-adapters> In this case the model address is "/subsystem=resource-adapters/resource-adapter=XXX". In case of second definition, console keeps displaying RA as "test" - since its the archive name. In case of definition with ID or one with '->#' this fails, since console depends on "getArchive()": https://github.com/hal/core/blob/master/gui/src/main/java/org/jboss/as/co... This affects WFLY and all previous release. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (AS7-4248) AS7 7.1.1.Final: java.lang.ClassCastException: org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory cannot be cast to javax.xml.crypto.dsig.XMLSignatureFactory

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-4248?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration updated AS7-4248: ----------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=979334 > AS7 7.1.1.Final: java.lang.ClassCastException: org.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory cannot be cast to javax.xml.crypto.dsig.XMLSignatureFactory > ---------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: AS7-4248 > URL: https://issues.jboss.org/browse/AS7-4248 > Project: Application Server 7 > Issue Type: Bug > Components: XML Frameworks > Affects Versions: 7.1.1.Final > Environment: jdk 1.6.0_31 > Reporter: Gianluca Mazzaferro > Assignee: Alessio Soldano > Priority: Minor > Fix For: 7.1.2.Final (EAP) > > > impossible to getInstance of a XMLSignatureFactory -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2481) CDI.current().getBeanManager() returns a beanmanager from a different deployment

by Max Pimm (JIRA)

[ https://issues.jboss.org/browse/WFLY-2481?page=com.atlassian.jira.plugin.... ] Max Pimm commented on WFLY-2481: -------------------------------- Woops. Just seen the pull request.... ignore that comment. > CDI.current().getBeanManager() returns a beanmanager from a different deployment > -------------------------------------------------------------------------------- > > Key: WFLY-2481 > URL: https://issues.jboss.org/browse/WFLY-2481 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Beta1 > Environment: WildFly master build > Reporter: Emond Papegaaij > Assignee: Jozef Hartinger > > CDI.current().getBeanManager() uses the classname of the calling class to cache BeanManagers returned. This fails if multiple deployments contain classes with the same name. For example, wicket-cdi-1.1 looks up the BeanManager from org.apache.wicket.cdi.CdiConfiguration. If multiple Wicket-CDI applications are deployed in the same container, every BeanManager lookup will return the instance cached on the first call. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-800) Deployment fails while previous message implies content was fine

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-800?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on WFLY-800: --------------------------------------- Is this fixed? The jboss-metadata PR was merged. Is that in WF now? > Deployment fails while previous message implies content was fine > ---------------------------------------------------------------- > > Key: WFLY-800 > URL: https://issues.jboss.org/browse/WFLY-800 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EE > Environment: Ubuntu Linux 12.10, x86_64 > Reporter: Jari Juslin > Assignee: David Lloyd > > In jboss-app.xml old style markup like this: > {code:xml} > <module-order>strict</module-order> > {code} > causes the whole deployment roll back. However, the deployer first claims it's OK and then throws undecipherable Exception message adding to the confusion. > It is OK to refuse to deploy because XML contains invalid element, but _not_ OK to fail to deploy and not tell that element was invalid, but instead suggest the XML was malformed, which it was not. > Beginning of the jboss-app.xml: > {code:xml} > <?xml version="1.0" encoding="UTF-8"?> > <jboss-app xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > version="7.0"> > <module-order>strict</module-order> > {code} > And the Exception: > {noformat} > 17:04:32,075 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "foo.ear" > 17:04:32,099 WARN [org.jboss.metadata.parser.jboss.JBossAppMetaDataParser] (MSC service thread 1-2) module-order element in jboss-app.xml is deprecated and has been ignored > 17:04:32,103 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."foo.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."foo.ear".STRUCTURE: Failed to process phase STRUCTURE of deployment "foo.ear" > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33] > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011059: Failed to parse "/content/foo.ear/META-INF/jboss-app.xml" > at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:123) > at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.deploy(EarMetaDataParsingProcessor.java:64) > at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final] > ... 5 more > Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag(). > at [row,col {unknown-source}]: [4,22] > at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606) > at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479) > at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464) > at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137) > at org.jboss.metadata.parser.jboss.JBossAppMetaDataParser.parse(JBossAppMetaDataParser.java:88) > at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:120) > ... 7 more > {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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2481) CDI.current().getBeanManager() returns a beanmanager from a different deployment

by Max Pimm (JIRA)

[ https://issues.jboss.org/browse/WFLY-2481?page=com.atlassian.jira.plugin.... ] Max Pimm commented on WFLY-2481: -------------------------------- I've been looking at this but before attempting a solution i thought i'd best run it by you. My idea is to add a LoadingCache<String, BeanManagerProxy> to EnhancedWeld for each root BDA. This could be stored as a map with the root BDA as the key. Can you see any problems with this? If not you can assign it to me. > CDI.current().getBeanManager() returns a beanmanager from a different deployment > -------------------------------------------------------------------------------- > > Key: WFLY-2481 > URL: https://issues.jboss.org/browse/WFLY-2481 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Beta1 > Environment: WildFly master build > Reporter: Emond Papegaaij > Assignee: Jozef Hartinger > > CDI.current().getBeanManager() uses the classname of the calling class to cache BeanManagers returned. This fails if multiple deployments contain classes with the same name. For example, wicket-cdi-1.1 looks up the BeanManager from org.apache.wicket.cdi.CdiConfiguration. If multiple Wicket-CDI applications are deployed in the same container, every BeanManager lookup will return the instance cached on the first call. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2105) It's possible to remove server group that are in use

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-2105?page=com.atlassian.jira.plugin.... ] Emanuel Muckenhuber reassigned WFLY-2105: ----------------------------------------- Assignee: Emanuel Muckenhuber (was: Brian Stansberry) > It's possible to remove server group that are in use > ---------------------------------------------------- > > Key: WFLY-2105 > URL: https://issues.jboss.org/browse/WFLY-2105 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Heiko Braun > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > > In use as in: > a) referenced from server configuration > b) referenced from server instance (running server) > IMO this should not be possible (consistency) -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2496) Concurrent access to ModuleSpecification causes race condition

by Jozef Hartinger (JIRA)

Jozef Hartinger created WFLY-2496: ------------------------------------- Summary: Concurrent access to ModuleSpecification causes race condition Key: WFLY-2496 URL: https://issues.jboss.org/browse/WFLY-2496 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Server Affects Versions: 8.0.0.Beta1 Reporter: Jozef Hartinger Assignee: Jason Greene Priority: Critical Fix For: 8.0.0.CR1 [ModuleSpecification|https://github.com/wildfly/wildfly/blob/master/server...] does not use any form of synchronization to protect its mutable state yet may be used from multiple threads in multi-module deployment when a DeploymentUnitProcessor touches ModuleSpecification of a different deployment unit which is processed at that moment. Here is an example of such access: https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/jav... Here's how I think this problem manifests: {noformat} Caused by: java.lang.NullPointerException at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createDependencies(ModuleSpecProcessor.java:284) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT] at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createModuleService(ModuleSpecProcessor.java:220) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT] at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deployModuleSpec(ModuleSpecProcessor.java:125) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT] at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deploy(ModuleSpecProcessor.java:88) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT] ... 5 more {noformat} and here's my attempt to verify concurrent access by changing the code slightly to deadlock on concurrent access: {noformat} "MSC service thread 1-6": at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f742ba28> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290) at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:170) at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121) at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115) at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) - locked <0x00000000f69a8e88> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) "MSC service thread 1-3": at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000000f742ba58> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290) at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:175) at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121) at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115) at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) - locked <0x00000000f6782960> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) {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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2421) PatchInfoUnitTestCase should be skipped in case that patching module is not enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2421?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2421: ----------------------------------------------- Aleksandar Kostadinov <akostadi(a)redhat.com> made a comment on [bug 1020315|https://bugzilla.redhat.com/show_bug.cgi?id=1020315] I will do once CR1 RPMs are ready. > PatchInfoUnitTestCase should be skipped in case that patching module is not enabled > ------------------------------------------------------------------------------------ > > Key: WFLY-2421 > URL: https://issues.jboss.org/browse/WFLY-2421 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Patching > Reporter: Jan Martiska > Assignee: Jan Martiska > Fix For: 8.0.0.CR1 > > > PatchInfoUnitTestCase should be skipped (rather than report a fail) in case that patching module is not enabled. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2208) CLI over HTTP should switch to / be redirected to https automatically.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2208?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-2208: ---------------------------------------- Just double checked, for pure management access we do already have a redirect from the unsecure port to the secure port - this is not happening for HTTP upgrade. > CLI over HTTP should switch to / be redirected to https automatically. > ---------------------------------------------------------------------- > > Key: WFLY-2208 > URL: https://issues.jboss.org/browse/WFLY-2208 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: CLI, Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 8.0.0.CR1 > > > When using the native interface a TLS upgrade was already automatically in place once a keystore was added to the linked realm. > With the switch to http with an upgrade there is no automatic switch to https. -- 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, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2013