October 2013 - jboss-jira - Jboss List Archives

[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

12 years, 9 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

12 years, 9 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

12 years, 9 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

12 years, 9 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

12 years, 9 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2248) Upgrade to JBoss SASL 1.0.4.CR1

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-2248: -------------------------------------- Summary: Upgrade to JBoss SASL 1.0.4.CR1 Key: WFLY-2248 URL: https://issues.jboss.org/browse/WFLY-2248 Project: WildFly Issue Type: Component Upgrade Components: Domain Management, Remoting, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 8.0.0.CR1 To allow relaxing the protocol check within the Digest MD5 mechanism. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2247) Add javax.transaction.api to JDBC module

by Jesper Pedersen (JIRA)

Jesper Pedersen created WFLY-2247: ------------------------------------- Summary: Add javax.transaction.api to JDBC module Key: WFLY-2247 URL: https://issues.jboss.org/browse/WFLY-2247 Project: WildFly Issue Type: Bug Components: JCA Affects Versions: 8.0.0.Beta1 Reporter: Jesper Pedersen Assignee: Stefano Maestri Fix For: 8.0.0.CR1 Add the javax.transaction.api module to the JDBC module such that people can use XA related classes during verification -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1592) Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails; credentials not accepted

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-1592?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-1592: ---------------------------------------- This issue is due to changes introduced in REM3-29 where the default protocol was switched from 'remote' to 'remoting'. Reverting that change would not be appropriate as it is needed to be able to enable GSSAPI support. The change for REM3-29 does allow the protocol name to be specified in configuration however doing that would require the same config on the server and in all clients - it would also only be a short term fix until we enable support for GSSAP. SASL-42 will instead allow the server side to specify a list of accepted alternative protocols, when GSSAPI is in use it will be essential for clients using it to use the correct protocol but older clients may still want to connect with username / password auth. > Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails; credentials not accepted > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1592 > URL: https://issues.jboss.org/browse/WFLY-1592 > Project: WildFly > Issue Type: Bug > Components: Remoting, Security > Affects Versions: 8.0.0.Alpha2 > Reporter: Rob Stryker > Assignee: Darran Lofthouse > Fix For: 8.0.0.CR1 > > > Using eap6.1 client jars, or the jboss-cli.sh script in a local eap6.1 installation, to connect to a remote wildfly alpha1 or alpha2, seems to work but fails when provided with credentials. This is most easily replicated as follows: > 1) On remote machine start wildfly alpha1 or alpha2 > 2) on local machine, cd eap-6.1/bin > 3) on local machine: > [rob@rawbdor bin]$ ./jboss-cli.sh > You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. > [disconnected /] connect myhost.net > Authenticating against security realm: ManagementRealm > Username: admin > Password: > Unable to authenticate against controller at myhost.net:9999: Authentication failed: all available authentication mechanisms failed > This is an issue for tools as we need a set of jars that communicates correctly with all as7 servers. We currently have a set of jars that communicates with all 7.x / eap 6.x, which is good. If this is merely a bug on the server, then we can hopefully delay having to bundle an additional set of client jars until larger breakages occur. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (SASL-42) Add option to relax protocol check within mechanisms.

by Darran Lofthouse (JIRA)

Darran Lofthouse created SASL-42: ------------------------------------ Summary: Add option to relax protocol check within mechanisms. Key: SASL-42 URL: https://issues.jboss.org/browse/SASL-42 Project: JBoss SASL Provider Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.4.CR1 The Digest MD5 mechanism contains a check that the URI received from the remote client matches the expected value, unfortunately older clients use a hard coded protocol or 'remote' - newer clients and servers use 'remoting'. This issue is to add a configuration option so that server side this checking can be relaxed, most appropriate would be to supply a list of accepted alternative protocols. -- 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, 9 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 October 2013