December 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4154) Provide an 'enable' parameter to the 'full-replace-deoplyment' operation

by Heiko Braun (JIRA)

Heiko Braun created WFLY-4154: --------------------------------- Summary: Provide an 'enable' parameter to the 'full-replace-deoplyment' operation Key: WFLY-4154 URL: https://issues.jboss.org/browse/WFLY-4154 Project: WildFly Issue Type: Feature Request Reporter: Heiko Braun Assignee: Jason Greene Similar to the /deployment=*:add() operation the /:full-replace-deployment() operarion should provide an 'enable' parameter that defines wether or not the deplyment should be enabled after the reaplcement. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4153) Incorrect interface definition in ejb-jar.xml for entity beans shows just NullPointer exception

by Chao Wang (JIRA)

Chao Wang created WFLY-4153: ------------------------------- Summary: Incorrect interface definition in ejb-jar.xml for entity beans shows just NullPointer exception Key: WFLY-4153 URL: https://issues.jboss.org/browse/WFLY-4153 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 9.0.0.Alpha1 Reporter: Chao Wang Assignee: Chao Wang Priority: Minor {noformat} In case that you specify interface type for entity bean in ejb-jar.xml that does not correspond with definition in the class of the bean then just Null Pointer exception is shown without any other info what's happening. I mean when you define bean through interface as remote and the ejb-jar.xml describes bean interfaces as local {code} public interface SomeBean extends EJBObject { ... } public interface SomeBeanHome extends EJBHome { ... } {code} and the ejb-jar.xml looks like {code} <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd" version="3.1"> <enterprise-beans> <entity> <ejb-name>SomeBean</ejb-name> <local-home>package.SomeBeanHome</local-home> <local>package.SomeBean</local> <ejb-class>package.SomeBeanBean</ejb-class> <persistence-type>Bean</persistence-type> <prim-key-class>java.lang.Integer</prim-key-class> <reentrant>true</reentrant> </entity> </enterprise-beans> </ejb-jar> {code} then NullPointerException is thrown {code} ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.deployment.unit."entitybeanbmp.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."entitybeanbmp.jar".INSTALL: JBAS018733: Failed to process phase INSTALL of deployment "entitybeanbmp.jar" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] 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_23] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23] Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011058: Failed to install component SimpleBMPBean at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:102) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT] ... 5 more Caused by: java.lang.NullPointerException at org.jboss.as.ejb3.component.entity.EntityBeanObjectViewConfigurator$2.configureDependency(EntityBeanObjectViewConfigurator.java:108) at org.jboss.as.ejb3.component.entity.EntityBeanObjectViewConfigurator$2.configureDependency(EntityBeanObjectViewConfigurator.java:105) at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:139) at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:95) ... 6 more {code} instead of some informative one. {noformat} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4152) clean up @deprecated for connector subsystem

by Jeff Zhang (JIRA)

Jeff Zhang created WFLY-4152: -------------------------------- Summary: clean up @deprecated for connector subsystem Key: WFLY-4152 URL: https://issues.jboss.org/browse/WFLY-4152 Project: WildFly Issue Type: Task Components: JCA Affects Versions: 9.0.0.Alpha1 Reporter: Jeff Zhang Assignee: Jeff Zhang Priority: Minor Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3872) Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3872?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3872: -------------------------------------- I tried running this in a loop 10000 times and could not reproduce it locally. When it fails we really need a thread dump of what is going on in Wildfly. I am not 100% convinced that this is an undertow issue, and not being able to reproduce it does not help. I might investigate how hard it would be to capture a thread dump on test failure in arquillian. > Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn > -------------------------------------------------------------------------------------------- > > Key: WFLY-3872 > URL: https://issues.jboss.org/browse/WFLY-3872 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > Since https://github.com/wildfly/wildfly/pull/6660 was submitted, EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn is failing regularly. Not every time but very often. > Alessio, you mentioned seeing some error logging from XAResourceRecoveryImpl, but that's in the logs on successful runs as well, and occurs prior to the test as well. That's a period background task from the transaction manager trying to perform recovery of some previous transaction. I don't see why it would have any impact on this test. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4056) Graceful shutdown for JMS

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4056?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-4056: -------------------------------------- Graceful shutdown is targeted for 9, if this piece is missing I don't think it will matter that much. We already have support for suspending MDB's, which I think is the main component. > Graceful shutdown for JMS > ------------------------- > > Key: WFLY-4056 > URL: https://issues.jboss.org/browse/WFLY-4056 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Stuart Douglas > Assignee: Jeff Mesnil > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1899) Discovery returns after 16 responses even if there are no coord responses

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1899?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1899: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1168329|https://bugzilla.redhat.com/show_bug.cgi?id=1168329] from MODIFIED to ON_QA > Discovery returns after 16 responses even if there are no coord responses > ------------------------------------------------------------------------- > > Key: JGRP-1899 > URL: https://issues.jboss.org/browse/JGRP-1899 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.2, 3.6.1 > > > Discovery sets {{Responses.num_expected_rsps}} to 16 if no member list is defined. This makes discovery return after 16 responses even if no response from a coordinator has been received. > This is a problem if we have a cluster of size > 16 and the coordinator doesn't respond imediately, e.g. because it is busy processing other requests. > h5. Solution > * Set {{num_expected_rsps}} to 0 (= wait until at least 1 coord rsp has been received -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-871) AdvancedLdapLoginModule should be able to retrieve password from Vault

by Derek Horton (JIRA)

[ https://issues.jboss.org/browse/SECURITY-871?page=com.atlassian.jira.plug... ] Derek Horton updated SECURITY-871: ---------------------------------- Git Pull Request: https://github.com/wildfly-security/jboss-negotiation/pull/20 > AdvancedLdapLoginModule should be able to retrieve password from Vault > ---------------------------------------------------------------------- > > Key: SECURITY-871 > URL: https://issues.jboss.org/browse/SECURITY-871 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Reporter: Derek Horton > Assignee: Darran Lofthouse > > AdvancedLdapLoginModule should be able to retrieve password from Vault -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-871) AdvancedLdapLoginModule should be able to retrieve password from Vault

by Derek Horton (JIRA)

Derek Horton created SECURITY-871: ------------------------------------- Summary: AdvancedLdapLoginModule should be able to retrieve password from Vault Key: SECURITY-871 URL: https://issues.jboss.org/browse/SECURITY-871 Project: PicketBox Issue Type: Bug Components: Negotiation Reporter: Derek Horton Assignee: Darran Lofthouse AdvancedLdapLoginModule should be able to retrieve password from Vault -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4149) NamingExceptions not properly handled in InitialContext

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4149?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4149: ----------------------------------------------- emartins(a)redhat.com changed the Status of [bug 1170359|https://bugzilla.redhat.com/show_bug.cgi?id=1170359] from NEW to ASSIGNED > NamingExceptions not properly handled in InitialContext > ------------------------------------------------------- > > Key: WFLY-4149 > URL: https://issues.jboss.org/browse/WFLY-4149 > Project: WildFly > Issue Type: Bug > Components: Naming > Reporter: David Lloyd > Assignee: Eduardo Martins > Fix For: 9.0.0.Beta1 > > > The change in https://github.com/jbossas/jboss-eap/commit/db525bf1d90a40eb909c8f915fca7... catches all Exception and rewraps them with NamingException. This behavior is undesirable if the original exception was already a NamingException. Catch and re-throw that exception type as-is before wrapping other exceptions. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4151) Spring Security with Active Directory Provider throwing Wrapped NamingException

by Bob Paulin (JIRA)

[ https://issues.jboss.org/browse/WFLY-4151?page=com.atlassian.jira.plugin.... ] Bob Paulin commented on WFLY-4151: ---------------------------------- Yes it is. Sorry for missing it. Closing. > Spring Security with Active Directory Provider throwing Wrapped NamingException > ------------------------------------------------------------------------------- > > Key: WFLY-4151 > URL: https://issues.jboss.org/browse/WFLY-4151 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.2.0.Final > Environment: Multiple > Reporter: Bob Paulin > Assignee: David Lloyd > > There is a bug logged against Spring Security for this issue as well https://jira.spring.io/browse/SEC-2754 > Providing the ActiveDirectoryLdapAuthenticationProvider with incorrect credentials causes internal server error when running on JBoss. > This is because ActiveDirectoryLdapAuthenticationProvider only considers top-level LdapExceptions, whereas JBoss seems to wrap exceptions thrown by InitialLdapContext into a top-level NamingException. > The issue does provide a suggested patch to spring security however I don't understand why Wildfly is wrapping the LdapExceptions when it did not appear to do this as late as JBoss EAP 6.2.0.GA -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 7 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 December 2014