October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2251) ; jsessionid=... in URL not supported

by Frank Cornelis (JIRA)

Frank Cornelis created WFLY-2251: ------------------------------------ Summary: ;jsessionid=... in URL not supported Key: WFLY-2251 URL: https://issues.jboss.org/browse/WFLY-2251 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 8.0.0.Beta1 Reporter: Frank Cornelis Assignee: Stuart Douglas Priority: Blocker When configuring a servlet within your Java EE application, you can reach it via: https://localhost/your_app_context/your_servlet_mapping but not via: https://localhost/your_app_context/your_servlet_mapping;jsessionid=whatever You get a "Not Found" error message instead. This used to work under JBoss EAP 6.1. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2250) Upgrade JGroups to 3.4.0.Final

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-2250: ---------------------------------- Summary: Upgrade JGroups to 3.4.0.Final Key: WFLY-2250 URL: https://issues.jboss.org/browse/WFLY-2250 Project: WildFly Issue Type: Component Upgrade Components: Clustering Affects Versions: 8.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 8.0.0.CR1 -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2176) JSF should be able to access the CDI-enabled ValidatorFactory

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-2176?page=com.atlassian.jira.plugin.... ] Farah Juma updated WFLY-2176: ----------------------------- Fix Version/s: 8.0.0.CR1 > JSF should be able to access the CDI-enabled ValidatorFactory > ------------------------------------------------------------- > > Key: WFLY-2176 > URL: https://issues.jboss.org/browse/WFLY-2176 > Project: WildFly > Issue Type: Feature Request > Components: JSF > Affects Versions: 8.0.0.Alpha4 > Reporter: Farah Juma > Assignee: Farah Juma > Fix For: 8.0.0.CR1 > > > Currently, for every deployment that uses JSF, the JSF subsystem adds the org.hibernate.validator module to the deployment. A ValidatorFactory is then obtained via the standard Bean Validation bootstrap strategy. However, a ValidatorFactory obtained this way isn't CDI-enabled. JSF needs to use the EE LazyValidatorFactory instead. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-364) a "failure-causes-rollback="false"" attribute for the filesystem scanner

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-364?page=com.atlassian.jira.plugin.s... ] Brian Stansberry reassigned WFLY-364: ------------------------------------- Assignee: Brian Stansberry > a "failure-causes-rollback="false"" attribute for the filesystem scanner > ------------------------------------------------------------------------ > > Key: WFLY-364 > URL: https://issues.jboss.org/browse/WFLY-364 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Reporter: Max Rydahl Andersen > Assignee: Brian Stansberry > Fix For: 8.0.0.CR1 > > > JBIDE-11509, AS7-783 and TORQUE-576 all talk about the problem of all deployments found at startup is deployed in one operation and if one deployment fails all is rolled back resulting in some rather bad usability issues - especially at development time, but even also at production time for those using file deployments. > Suggestion on irc was that there could be an option on the file scanner (possibly false by default?) to say that failure causes rollback. > Individual deployments could then still fail, but at least not everything would be rolledback and it would still allow proper interdependent deployments to work. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-446) Add quickstarts info to localhost:8080

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/WFLY-446?page=com.atlassian.jira.plugin.s... ] Pete Muir resolved WFLY-446. ---------------------------- Fix Version/s: (was: 8.0.0.CR1) Resolution: Out of Date Now out of date, quickstarts target EAP. > Add quickstarts info to localhost:8080 > -------------------------------------- > > Key: WFLY-446 > URL: https://issues.jboss.org/browse/WFLY-446 > Project: WildFly > Issue Type: Task > Reporter: Pete Muir > Assignee: Pete Muir > Priority: Minor > > Add another static page, quickstarts.html, that lists the quickstarts available and how to get them. Add a link from the main page. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2240) Modcluster transformers for 7.2.0

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2240?page=com.atlassian.jira.plugin.... ] Radoslav Husar reassigned WFLY-2240: ------------------------------------ Assignee: Radoslav Husar (was: Jean-Frederic Clere) I ll take it as im working on the related transformers. > Modcluster transformers for 7.2.0 > --------------------------------- > > Key: WFLY-2240 > URL: https://issues.jboss.org/browse/WFLY-2240 > Project: WildFly > Issue Type: Sub-task > Components: Clustering > Reporter: Kabir Khan > Assignee: Radoslav Husar > Fix For: 8.0.0.CR1 > > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2249) NPE during redeployment of a war

by Juergen Zimmermann (JIRA)

Juergen Zimmermann created WFLY-2249: ---------------------------------------- Summary: NPE during redeployment of a war Key: WFLY-2249 URL: https://issues.jboss.org/browse/WFLY-2249 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Affects Versions: 8.0.0.Beta1 Reporter: Juergen Zimmermann Assignee: Scott Marlow When I redeploy an already running war, then I get the following NPE. The (re-) deployment is done via the Maven plugin org.jboss.as.plugins:jboss-as-maven-plugin:7.4.Final. It looks like the redployment was successful anyway. Hmm... {code} ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.war".PARSE: JBAS018733: Failed to process phase PARSE of deployment "shop.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] Caused by: java.lang.NullPointerException at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.handleWarDeployment(PersistenceUnitParseProcessor.java:126) at org.jboss.as.jpa.processor.PersistenceUnitParseProcessor.deploy(PersistenceUnitParseProcessor.java:83) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1.jar:8.0.0.Beta1] ... 5 more {code} -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1547) deploy directories not cleaned up

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1547: ----------------------------------------------- Nikoleta Ziakova <nziakova(a)redhat.com> changed the Status of [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383] from ON_QA to VERIFIED > deploy directories not cleaned up > --------------------------------- > > Key: WFLY-1547 > URL: https://issues.jboss.org/browse/WFLY-1547 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.0.0.Alpha1 > Reporter: Shaun Appleton > Assignee: jaikiran pai > Fix For: 8.0.0.Beta1 > > Attachments: deployment_with_hack_no_hook.txt > > > JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories. > The following reproduces this - > i) ensure run.conf has the -Xrs set > ii) ensure deployments has a deployable .ear in it > iii) ./run standalone.sh and allow the deployments to deploy > iv) stop the EAP process ie kill <process_id> > v) observe content tmp/vfs > (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP) > This will eventually cause problems with lack of disk space. > Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems. > It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1547) deploy directories not cleaned up

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1547: ----------------------------------------------- Nikoleta Ziakova <nziakova(a)redhat.com> made a comment on [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383] Thank you. Verified for EAP 6.2.0 ER3. > deploy directories not cleaned up > --------------------------------- > > Key: WFLY-1547 > URL: https://issues.jboss.org/browse/WFLY-1547 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.0.0.Alpha1 > Reporter: Shaun Appleton > Assignee: jaikiran pai > Fix For: 8.0.0.Beta1 > > Attachments: deployment_with_hack_no_hook.txt > > > JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories. > The following reproduces this - > i) ensure run.conf has the -Xrs set > ii) ensure deployments has a deployable .ear in it > iii) ./run standalone.sh and allow the deployments to deploy > iv) stop the EAP process ie kill <process_id> > v) observe content tmp/vfs > (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP) > This will eventually cause problems with lack of disk space. > Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems. > It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-101) JMSService.start is doing blocking I/O

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on WFLY-101: ---------------------------------------------- Miroslav Novak <mnovak(a)redhat.com> made a comment on [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913] Hi Jeff, could you help with verification of this bz, please? I can see that PR contains actually more than one thing. "HornetQ fail-back results in XA recovery warnings" I can verify easily. Problem is "[WFLY-101] JMSService.start to perform blocking I/O asynchronously" I guess only way to verify is to read the code, right? > JMSService.start is doing blocking I/O > -------------------------------------- > > Key: WFLY-101 > URL: https://issues.jboss.org/browse/WFLY-101 > Project: WildFly > Issue Type: Bug > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.0.Alpha1 > > > flag the start context as asynchronous -- 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, 3 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 October 2013