January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1612) Write test for EJB TimerService creating empty directories

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-1612?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-1612. ---------------------------------- Resolution: Rejected > Write test for EJB TimerService creating empty directories > ---------------------------------------------------------- > > Key: WFLY-1612 > URL: https://issues.jboss.org/browse/WFLY-1612 > Project: WildFly > Issue Type: Enhancement > Components: EJB, Test Suite > Reporter: Navin Surtani > Assignee: Navin Surtani > Priority: Minor > > WFLY-28 was completed which fixes a bug where the EJB TimerService creates empty directories for all ejbs, even though they don't have timers. > There isn't any test for this within the WildFly codebase, there should ideally be a test to prevent the bug from re-occurring. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3600) TransactionRolledbackException doesn't reference the originating runtime-exception

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3600?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3600: -------------------------------------- I don't think this is actually possible, we are required to throw TransactionRolledbackException by spec, and this exception explicitly disallows initialising a cause. > TransactionRolledbackException doesn't reference the originating runtime-exception > ---------------------------------------------------------------------------------- > > Key: WFLY-3600 > URL: https://issues.jboss.org/browse/WFLY-3600 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > > If a RuntimeException is thrown by a business method this gets lost during propagation to the client. > The client is not able in this case to react appropriate to the cause. > Similar issue was fixed for the Local invocation, see AS7-5432 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2967) Rationalize log-and-throw behavior in CMTTxInterceptor.handleInCallerTx

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2967?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-2967: -------------------------------------- I have removed this behaviour, we already have some rather unfortunate log and re-throw behaviour in the logging interceptor, which basically means that at the moment an exception may be logged twice for every EJB on the call stack (e.g. a servlet that called a chain of 3 EJB's could result in the exception being logged 7 times). This should never have been there in the first place IMHO. > Rationalize log-and-throw behavior in CMTTxInterceptor.handleInCallerTx > ----------------------------------------------------------------------- > > Key: WFLY-2967 > URL: https://issues.jboss.org/browse/WFLY-2967 > Project: WildFly > Issue Type: Task > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Stuart Douglas > > CMTTxInterceptor.handleInCallerTx does a log-and-throw: > {code} > setRollbackOnly(tx); > EjbLogger.ROOT_LOGGER.error(t); > throw (Exception) t; > {code} > Generally this is an anti-pattern, although there may be utility in logging some events server-side as an aid in diagnostics or something. IMO if the exception indicates some sort of server fault, as opposed to a client or application state mistake, it needs to be logged server-side. But I'm not sure where the dividing line is. > It doesn't look like this particular example is nicely playing such a role though. > 1) It's only called in MANDATORY/REQUIRED/SUPPORTS scenarios where a tx already exists. So, what it logs is logged in some scenarios and not in others. > 2) It logs stuff that looks pretty clearly like client mistakes, in particular NoSuchEJBException and NoSuchEntityException. I don't believe these add value to the server log, at least not at a level above DEBUG. > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3444) EjbTimerXmlPersister should check if timer.getNextExpiration() is null to avoid NPE

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3444?page=com.atlassian.jira.plugin.... ] Stuart Douglas reopened WFLY-3444: ---------------------------------- Assignee: Stuart Douglas (was: David Lloyd) > EjbTimerXmlPersister should check if timer.getNextExpiration() is null to avoid NPE > ----------------------------------------------------------------------------------- > > Key: WFLY-3444 > URL: https://issues.jboss.org/browse/WFLY-3444 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Scott Marlow > Assignee: Stuart Douglas > Fix For: 9.0.0.Beta1 > > > Seeing a NPE in org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister. that probably needs a null check: > {quote} > Caused by: java.lang.NullPointerException > at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeCalendarTimer(EjbTimerXmlPersister.java:136) > at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeContent(EjbTimerXmlPersister.java:89) > at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeContent(EjbTimerXmlPersister.java:43) > at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) > at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) > at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.writeFile(FileTimerPersistence.java:440) > {quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3444) EjbTimerXmlPersister should check if timer.getNextExpiration() is null to avoid NPE

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3444?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-3444. ---------------------------------- Resolution: Done > EjbTimerXmlPersister should check if timer.getNextExpiration() is null to avoid NPE > ----------------------------------------------------------------------------------- > > Key: WFLY-3444 > URL: https://issues.jboss.org/browse/WFLY-3444 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Scott Marlow > Assignee: David Lloyd > Fix For: 9.0.0.Beta1 > > > Seeing a NPE in org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister. that probably needs a null check: > {quote} > Caused by: java.lang.NullPointerException > at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeCalendarTimer(EjbTimerXmlPersister.java:136) > at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeContent(EjbTimerXmlPersister.java:89) > at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeContent(EjbTimerXmlPersister.java:43) > at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88) > at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83) > at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.writeFile(FileTimerPersistence.java:440) > {quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4097) JAX-RS Returns Wrong Repsonse Code When A Method Is Not Allowed

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-4097?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-4097. ---------------------------------- Resolution: Rejected This is not a bug. To return a 403 response code you need to create an ExceptionMapper for the EjbAccessException that can return any response you want. > JAX-RS Returns Wrong Repsonse Code When A Method Is Not Allowed > --------------------------------------------------------------- > > Key: WFLY-4097 > URL: https://issues.jboss.org/browse/WFLY-4097 > Project: WildFly > Issue Type: Bug > Components: EJB, REST, Security > Affects Versions: 8.1.0.Final > Environment: Windows 7 > Java 8u25 > WildFly 8.1.0.Final > Reporter: shinzey shinzey > Assignee: David Lloyd > Priority: Critical > > My RESTful service is protected with @RolesAllowed: > {quote} > @Stateless > @RolesAllowed("admin") > @Path("admin") > {quote} > When a non-admin user is trying to request this service, it fails with 500 Internal Server Error, instead of 403 Forbidden. From the log we can see that @RolesAllowed is working as expected: > {quote} > org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBAccessException: JBAS014502: Invocation on method: public zhyi.wildweb.AdminService zhyi.wildweb.AdminService.getUsers() of bean: AdminService is not allowed > {quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2967) Rationalize log-and-throw behavior in CMTTxInterceptor.handleInCallerTx

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-2967?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-2967: ------------------------------------ Assignee: Stuart Douglas (was: David Lloyd) > Rationalize log-and-throw behavior in CMTTxInterceptor.handleInCallerTx > ----------------------------------------------------------------------- > > Key: WFLY-2967 > URL: https://issues.jboss.org/browse/WFLY-2967 > Project: WildFly > Issue Type: Task > Components: EJB > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Stuart Douglas > > CMTTxInterceptor.handleInCallerTx does a log-and-throw: > {code} > setRollbackOnly(tx); > EjbLogger.ROOT_LOGGER.error(t); > throw (Exception) t; > {code} > Generally this is an anti-pattern, although there may be utility in logging some events server-side as an aid in diagnostics or something. IMO if the exception indicates some sort of server fault, as opposed to a client or application state mistake, it needs to be logged server-side. But I'm not sure where the dividing line is. > It doesn't look like this particular example is nicely playing such a role though. > 1) It's only called in MANDATORY/REQUIRED/SUPPORTS scenarios where a tx already exists. So, what it logs is logged in some scenarios and not in others. > 2) It logs stuff that looks pretty clearly like client mistakes, in particular NoSuchEJBException and NoSuchEntityException. I don't believe these add value to the server log, at least not at a level above DEBUG. > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-871?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-871: -------------------------------------------------- Dominik Pospisil <dpospisi(a)redhat.com> changed the Status of [bug 1170764|https://bugzilla.redhat.com/show_bug.cgi?id=1170764] from POST to MODIFIED > AdvancedLdapLoginModule should be able to retrieve bindCredential 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 > Fix For: Negotiation_2_3_6_Final > > > AdvancedLdapLoginModule should be able to retrieve bindCredential from Vault -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1366) @DataSourceDefinition incorrectly requires other properties than name and class-name

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-1366?page=com.atlassian.jira.plugin.... ] Tomasz Adamski reopened WFLY-1366: ---------------------------------- > @DataSourceDefinition incorrectly requires other properties than name and class-name > ------------------------------------------------------------------------------------ > > Key: WFLY-1366 > URL: https://issues.jboss.org/browse/WFLY-1366 > Project: WildFly > Issue Type: Feature Request > Components: EE > Affects Versions: 8.0.0.Alpha1 > Reporter: arjan tijms > Assignee: Tomasz Adamski > Labels: spec, validation > > When using the <data-source> element in e.g. web.xml or application.xml JBoss EAP 6.0.1/JBoss AS 7.1.3 does not accept a configuration without properties other than {{name}} and {{class-name}}. For instance: > {code:xml} > <data-source> > <name>java:app/myDS</name> > <class-name>com.example.MyDS</class-name> > </data-source> > {code} > With such configuration, the following exception is thrown: > {noformat} > Caused by: org.jboss.jca.common.api.validator.ValidateException: IJ010069: Missing required element xa-datasource-property in org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl > at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.validate(XADataSourceImpl.java:385) > at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.<init>(XADataSourceImpl.java:116) > at org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl.<init>(XADataSourceImpl.java:76) > at org.jboss.as.connector.subsystems.datasources.ModifiableXaDataSource.getUnModifiableInstance(ModifiableXaDataSource.java:373) > at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.getDeployer(XaDataSourceService.java:70) > at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:116) > {noformat} > At the point where the exception is thrown, the code checks if there are any properties at all: > {code} > if (this.xaDataSourceProperty.isEmpty()) > throw new ValidateException( > bundle.requiredElementMissing( > Tag.XA_DATASOURCE_PROPERTY.getLocalName(), > this.getClass().getCanonicalName())); > {code} > I don't understand why this check is there. If I'm not mistaken the spec (e.g. JSR 250 section 2.13 and JSR 316 section EE.5.17) does not seem to mandate properties to be present and the corresponding annotation only requires {{name}} and {{className}} to be specified. > A workaround is to subclass the data source class and provide a dummy property, e.g. > {code:xml} > <data-source> > <name>java:app/myDS</name> > <class-name>com.example.MySubDS</class-name> > <property> > <name>dummy</name> > <value>dummy</value> > </property> > </data-source> > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4230) Module org.infinispan.client.hotrod references non-existing module com.google.protobuf

by Johannes Beck (JIRA)

Johannes Beck created WFLY-4230: ----------------------------------- Summary: Module org.infinispan.client.hotrod references non-existing module com.google.protobuf Key: WFLY-4230 URL: https://issues.jboss.org/browse/WFLY-4230 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 8.2.0.Final Reporter: Johannes Beck Assignee: Paul Ferraro Priority: Minor The module org.infinispan.client.hotrod has a dependency to com.google.protobuf, but com.google.protobuf does not exist. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015