February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3030) Test Suite is not security manager-aware

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3030?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-3030: ----------------------------------- I think biggest issue is that Embedded arq tests fail and leave instance behind and everything else just fails as result of that. > Test Suite is not security manager-aware > ---------------------------------------- > > Key: WFLY-3030 > URL: https://issues.jboss.org/browse/WFLY-3030 > Project: WildFly > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.0.0.Final > Reporter: David Lloyd > > Our test suite has over 1000 failures running in security manager mode ({{-Dsecurity.manager}}). These are due in large part to missing {{permissions.xml}} files. Just adding these files to each test/arq deployment should cut the number of failures down dramatically. > Once this is done, individual test failures can be tackled. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3030) Test Suite is not security manager-aware

by David Lloyd (JIRA)

David Lloyd created WFLY-3030: --------------------------------- Summary: Test Suite is not security manager-aware Key: WFLY-3030 URL: https://issues.jboss.org/browse/WFLY-3030 Project: WildFly Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Affects Versions: 8.0.0.Final Reporter: David Lloyd Our test suite has over 1000 failures running in security manager mode ({{-Dsecurity.manager}}). These are due in large part to missing {{permissions.xml}} files. Just adding these files to each test/arq deployment should cut the number of failures down dramatically. Once this is done, individual test failures can be tackled. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-951) It is not possible to enable AtomicActionExpiryScanner in EAP 6.x

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-951?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson updated WFLY-951: ------------------------------- Assignee: Tom Jenkinson > It is not possible to enable AtomicActionExpiryScanner in EAP 6.x > ----------------------------------------------------------------- > > Key: WFLY-951 > URL: https://issues.jboss.org/browse/WFLY-951 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transactions > Environment: JBoss EAP 6.01 > Reporter: Tom Ross > Assignee: Tom Jenkinson > > It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below: > {noformat} > <system-properties> > <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/> > </system-properties> > {noformat} > Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no easy way of removing transaction manager debris from object store. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-364) ClasspathKieProject fails vfs: path for jar deployments and exploded ear

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-364?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-364: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1058254|https://bugzilla.redhat.com/show_bug.cgi?id=1058254] from ASSIGNED to MODIFIED > ClasspathKieProject fails vfs: path for jar deployments and exploded ear > ------------------------------------------------------------------------ > > Key: DROOLS-364 > URL: https://issues.jboss.org/browse/DROOLS-364 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Final > Environment: JBoss AS 7.1.1 > Reporter: Nicolas-Xavier Vanderlinden > Assignee: Mario Fusco > Fix For: 6.1.0.Beta1 > > Attachments: jbossas-deploy-reproducer.zip, windows-jboss-as-deploy-server.log > > > Drools is not able to load kmodule.xml from an exploded ear. > 17:24:45,116 WARN Unable to load pom.properties tried recursing down from\Project\Geline\jboss-as-7.1.1.Final\standalone\deployments\geline.ear\service-impl-1.4.0-SNAPcontent > null > 17:24:45,116 ERROR Unable to build index of kmodule.xml url=vfs:/E:/Project/Geline/jboss-as-7.1.1.Final/standalone/deployments/geline.ear/service-impl-1.4.0-SNAPSHOT.jar/META-INF/kmodule.xml > null -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1140) New option for <validate-on-match/> policy

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1140?page=com.atlassian.jira.plugin... ] Jesper Pedersen updated JBJCA-1140: ----------------------------------- Component/s: JDBC (was: Code Generator) > New option for <validate-on-match/> policy > ------------------------------------------ > > Key: JBJCA-1140 > URL: https://issues.jboss.org/browse/JBJCA-1140 > Project: IronJacamar > Issue Type: Feature Request > Components: JDBC > Environment: JBoss EAP 6.2.0 > Reporter: Tom Ross > Assignee: Jesper Pedersen > > There is a requirement for a new option in the pool connection validation. > <validate-on-match/> should validate, except if the connection has been returned recently into the pool for instance in the last 10 secs. > The reasoning is that if the connection has been used in the last 10 secs, and it is consider as checked. so it is not worth doing an extra validation. > The only way this could be approached at the moment would be to use more aggressively background validation. But this would put more needless pressure on the db considering all pool filled with many connections that will take time to shrink down. > With the proposed solution, would be the best of both worlds: an active application does not pay for the price of validation before use, although it uses checked connections, without having to schedule aggressive background checks. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1140) New option for <validate-on-match/> policy

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1140?page=com.atlassian.jira.plugin... ] Jesper Pedersen closed JBJCA-1140. ---------------------------------- Resolution: Rejected Should be done using a custom checker implementation > New option for <validate-on-match/> policy > ------------------------------------------ > > Key: JBJCA-1140 > URL: https://issues.jboss.org/browse/JBJCA-1140 > Project: IronJacamar > Issue Type: Feature Request > Components: JDBC > Environment: JBoss EAP 6.2.0 > Reporter: Tom Ross > Assignee: Jesper Pedersen > > There is a requirement for a new option in the pool connection validation. > <validate-on-match/> should validate, except if the connection has been returned recently into the pool for instance in the last 10 secs. > The reasoning is that if the connection has been used in the last 10 secs, and it is consider as checked. so it is not worth doing an extra validation. > The only way this could be approached at the moment would be to use more aggressively background validation. But this would put more needless pressure on the db considering all pool filled with many connections that will take time to shrink down. > With the proposed solution, would be the best of both worlds: an active application does not pay for the price of validation before use, although it uses checked connections, without having to schedule aggressive background checks. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3029) add remove-jndi operations to JMS resources

by Jeff Mesnil (JIRA)

Jeff Mesnil created WFLY-3029: --------------------------------- Summary: add remove-jndi operations to JMS resources Key: WFLY-3029 URL: https://issues.jboss.org/browse/WFLY-3029 Project: WildFly Issue Type: Enhancement Security Level: Public (Everyone can see) Components: JMS Affects Versions: 8.0.0.Final Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 8.0.1.Final JMS resources have a "add-jndi" operation to add a JNDI binding to their entries attribute but there is no mechanism to remove one JNDI binding. A remove-jndi operation must be added to handle this use case. -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2948) Welcome file does not work for *.jsf

by Gulam Samdani (JIRA)

[ https://issues.jboss.org/browse/WFLY-2948?page=com.atlassian.jira.plugin.... ] Gulam Samdani closed WFLY-2948. ------------------------------- Resolution: Done > Welcome file does not work for *.jsf > -------------------------------------- > > Key: WFLY-2948 > URL: https://issues.jboss.org/browse/WFLY-2948 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (JBoss Web) > Affects Versions: 8.0.0.Final > Reporter: Gulam Samdani > Assignee: Remy Maucherat > Priority: Minor > Fix For: 8.0.1.Final > > > Welcome file does not work for *.jsf > -------------------------------------------------------- > same problem not exists in Wildfly Beta but wildfly 8 final /cr1 gives this error ... > > problem : > > http://localhost:8080/hello ------------------------------ NO works*** > @http://localhost:8080/hello/index.jsf ------------- it works fine > ======================================= > <welcome-file-list> > > <welcome-file>index.jsf</welcome-file> > > </welcome-file-list> > <servlet> > <servlet-name>Faces Servlet</servlet-name> > <servlet-class>javax.faces.webapp.FacesServlet</servlet-class> > <load-on-startup>1</load-on-startup> > </servlet> > <servlet-mapping> > <servlet-name>Faces Servlet</servlet-name> > <url-pattern>*.jsf</url-pattern> > </servlet-mapping> > </web-app> > ------------------------------------------------- > Reproduce this error : > https://community.jboss.org/message/857300 -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2580) keytool-maven-plugin does not work on JDK8

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2580?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2580: ----------------------------------------------- Tomaz Cerar <tcerar(a)redhat.com> changed the Status of [bug 1066773|https://bugzilla.redhat.com/show_bug.cgi?id=1066773] from NEW to MODIFIED > keytool-maven-plugin does not work on JDK8 > ------------------------------------------ > > Key: WFLY-2580 > URL: https://issues.jboss.org/browse/WFLY-2580 > Project: WildFly > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.0.0.Beta1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 8.0.0.Final > > > JDK8 has changed JarSigner package / class location > upstream issue https://jira.codehaus.org/browse/MKEYTOOL-35 -- 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3028) It should be possible to initialize Filters on deployment rather than on first use

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-3028?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-3028: --------------------------------- Assignee: Tomaz Cerar (was: David Lloyd) > It should be possible to initialize Filters on deployment rather than on first use > ---------------------------------------------------------------------------------- > > Key: WFLY-3028 > URL: https://issues.jboss.org/browse/WFLY-3028 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Undertow) > Affects Versions: 8.0.0.CR1 > Environment: Ubuntu 12.04.1 LTS 32b | JVM 1.7 | > Reporter: Nicolas Barrera > Assignee: Tomaz Cerar > Labels: servletfilter > > As I see it Wildfly “Lazy-Inits” Filters, and that's causing some problems in my project, here is my case: > It happens that I have a filter chain declared in web.xml > FilterA -> FilterB > so that when a new request arrives FilterA is executed first and FilterB second. > My problem is that FilterA needs FilterB to be initialized before it's filter method is executed. > When using other web containers (tomcat/jetty) I had no problem with this scenario because filters' init method is called on server startup. > With wildfly the init method of a Filter is not called until it receives the first request so the methods would be called in this order: > FilterA.init, FilterA.filter, FilterB.init, FilterB.filter > and FilterA.filter will fail because FilterB.init wasn't called earlier. > Maybe it's ok to have certain mode where Filters are initialized lazily but I 'd like to have some configuration option that let me initialize filters on startup. > I 've asked on stackoverflow about this problem and after a while only one person showed up and recommended me to raise a JIRA, so I assumed this was not possible in Wildfly 8. -- 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, 4 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 February 2014