November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2498) Logout of secured (ssl) admin console setup redirects to http address

by Chris Dolphy (JIRA)

[ https://issues.jboss.org/browse/WFLY-2498?page=com.atlassian.jira.plugin.... ] Chris Dolphy updated WFLY-2498: ------------------------------- Description: Description of problem: Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found error. was: Description of problem: Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found error. Steps to Reproduce: 1. Setup HTTPS for admin console (I uesd the standalone instructions at https://access.redhat.com/site/solutions/229963) 2. Login to admin console (e.g. https://localhost:9443/console) 3. Click logout button and see address bar go to http address. Steps to Reproduce: Steps to Reproduce: 1. Setup HTTPS for admin console (I uesd the standalone instructions at https://access.redhat.com/site/solutions/229963) 2. Login to admin console (e.g. https://localhost:9443/console) 3. Click logout button and see address bar go to http address. > Logout of secured (ssl) admin console setup redirects to http address > ---------------------------------------------------------------------- > > Key: WFLY-2498 > URL: https://issues.jboss.org/browse/WFLY-2498 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Console > Reporter: Chris Dolphy > Assignee: Heiko Braun > > Description of problem: > Logging out of an admin console secured with SSL (on port 9443) redirects to http address (e.g. http://localhost:9443/logout?logout) which leads to a Page Not Found error. -- 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

11 years, 2 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: (was: Perform) Bugzilla References: (was: 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

11 years, 2 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 commented on AS7-4248: ---------------------------------------------- kconner(a)redhat.com made a comment on [bug 979334|https://bugzilla.redhat.com/show_bug.cgi?id=979334] An alternative could be to provide a modified version of ./modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-1.5.3-redhat-1.jar that removed the javax.xml.crypto packages. > 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

11 years, 2 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 commented on AS7-4248: ---------------------------------------------- kconner(a)redhat.com made a comment on [bug 979334|https://bugzilla.redhat.com/show_bug.cgi?id=979334] The workaround is to edit modules/system/layers/base/javax/api/main/module.xml and *comment out* the following lines  Once this is done there will be no attempt to load these packages from the JDK. > 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

11 years, 2 months

1
0
0 / 0

[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

11 years, 2 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

11 years, 2 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

11 years, 2 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

11 years, 2 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

11 years, 2 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

11 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2013