June 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-2676) CLI parameter prompting

by Nicklas Karlsson (Created) (JIRA)

CLI parameter prompting ----------------------- Key: AS7-2676 URL: https://issues.jboss.org/browse/AS7-2676 Project: Application Server 7 Issue Type: Feature Request Components: CLI Affects Versions: 7.1.0.Alpha1 Reporter: Nicklas Karlsson Assignee: Alexey Loubyansky Priority: Minor It could be handy if there was some mechanism for prompting for values (with included default value). That way one could have a master script that could be run for a new AS and you would be prompted for changing parameters (e.g. datsource jdbc urls, transaction timeouts etc) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
3
0 / 0

[JBoss JIRA] (AS7-5046) try-catch-finally control flow for cli

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created AS7-5046: -------------------------------------- Summary: try-catch-finally control flow for cli Key: AS7-5046 URL: https://issues.jboss.org/browse/AS7-5046 Project: Application Server 7 Issue Type: Task Components: CLI Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Fix For: 7.2.0.Alpha1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
1
0 / 0

[JBoss JIRA] (JBRULES-3548) Easy version bumping during release procedure: Fix script update-version-all.sh

by Geoffrey De Smet (JIRA)

13 years, 9 months

2
5
0 / 0

[JBoss JIRA] (AS7-4397) console uses relative paths for redirections

by Aleksandar Kostadinov (JIRA)

Aleksandar Kostadinov created AS7-4397: ------------------------------------------ Summary: console uses relative paths for redirections Key: AS7-4397 URL: https://issues.jboss.org/browse/AS7-4397 Project: Application Server 7 Issue Type: Bug Components: Console Affects Versions: 7.1.1.Final Reporter: Aleksandar Kostadinov Assignee: Heiko Braun Console uses relative address in Location header when redirecting: $ curl -v localhost:9990 * About to connect() to localhost port 9990 (#0) * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 9990 (#0) > GET / HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.12.9.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2 > Host: localhost:9990 > Accept: */* > < HTTP/1.1 301 Moved Permanently < Transfer-encoding: chunked < Location: /console/index.html < Date: Wed, 04 Apr 2012 12:50:14 GMT < * Connection #0 to host localhost left intact * Closing connection #0 This is a problem running a reverse proxy to server the console. RFC 1945 requires that to be a complete absolute URI [1]. The problem is that mod_proxy expects a complete URI. The problem manifests when proxying is performed on path other than ROOT of the http server (e.g. you open http://server_public_hostname/asconsole to access console). A typical mod_proxy configuration in this case would be: ProxyPass /asconsole/ http://localhost:9990/ ProxyPassReverse /asconsole/ http://localhost:9990/ ProxyPassReverseCookiePath / /asconsole/ ProxyPassReverseCookieDomain localhost server_public_hostname redirects in this case are not translated by mod_proxy because it matches against string "http://localhost:9990/". And one is redirected to /something instead of /asconsole/something. curl output: curl -v http://my_public_hostname/asconsole * About to connect() to my_public_hostname port 80 (#0) * Trying 24.24.164.76... connected * Connected to my_public_hostname (24.24.164.76) port 80 (#0) > GET /asconsole HTTP/1.1 > User-Agent: curl/7.21.0 (i486-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6 > Host: my_public_hostname > Accept: */* > < HTTP/1.1 301 Moved Permanently < Date: Wed, 04 Apr 2012 12:29:30 GMT < Location: /console/index.html < Connection: close < Transfer-Encoding: chunked < Content-Type: text/plain; charset=UTF-8 < * Closing connection #0 The workarounds are described in the workaround section. I'm not really sure what the best approach for this problem would be. Using the Host header of request makes some sense but if one already uses ProxyPreserveHost On then it can also affect this functionality. Hardcoding the URL would be a complication to configuration. Perhaps making the behavior configurable and documented would be best. [1] http://en.wikipedia.org/wiki/HTTP_location -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
10
0 / 0

[JBoss JIRA] Created: (JBAS-8390) Allow for configuration of respawn policy in host.xml/domain.xml

by Kabir Khan (JIRA)

Allow for configuration of respawn policy in host.xml/domain.xml ---------------------------------------------------------------- Key: JBAS-8390 URL: https://jira.jboss.org/browse/JBAS-8390 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Fix For: 7.0.0.M1 The server manager currently uses the default respawn policy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
6
0 / 0

[JBoss JIRA] (AS7-3972) Review module name of remotingjmx

by Darran Lofthouse (JIRA)

Darran Lofthouse created AS7-3972: ------------------------------------- Summary: Review module name of remotingjmx Key: AS7-3972 URL: https://issues.jboss.org/browse/AS7-3972 Project: Application Server 7 Issue Type: Task Components: JMX Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.1.1.Final Current module should be retained for backwards compatibility. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
3
0 / 0

[JBoss JIRA] (JGRP-1486) Merge failure when dead instances remain in view

by David Hotham (JIRA)

David Hotham created JGRP-1486: ---------------------------------- Summary: Merge failure when dead instances remain in view Key: JGRP-1486 URL: https://issues.jboss.org/browse/JGRP-1486 Project: JGroups Issue Type: Bug Affects Versions: 3.0.10 Reporter: David Hotham Assignee: Bela Ban I've hit this testing my JGRP-1485 fix, but I think it's a logically independent issue. So, I've reached a point where: - A, B and C all have view {C,A,B} - D has view {B', D', D, A', C}, in which B', D' and A' are all dead instances As in JGRP-1485, an optimal fix would surely be to allow D to recover all by itself, but it's not clear to me how to do that. However, my expectation was that a merge should sort things out; and I think that if it did then that ought to be good enough. But what's actually happening is this: - C becomes merge leader - determines that merge participants are C, D', D, A' - sends MERGE_REQ to those members - the MERGE_REQ to D' reaches D (and that to A' reaches A) - D sends a positive response for the MERGE_REQ that was meant for it, but after 2.5 seconds also sends a negative response to the MERGE_REQ meant for D'. (I think that the negative response is because it can't fetch the digest from D') - likewise A sends a negative response to the MERGE_REQ meant for A' So what C sees is: - good responses from C and D, followed by merge_rejected responses from A and D - so it removes A' and D' from the merge (it didn't get responses from them) - then it removes D from the merge (because the most recent response from D said merge_rejected) - so it is left only with itself, and comes up with a consolidated view that is identical to its original view in short: the merge doesn't do anything useful after all. I think that the key here is the confusion between D and D'. Possibly the fix is as simple as: ignore MERGE_REQs where the destination address on the message is not the local address. I'll try this out and, if it looks good, submit a pull request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
6
0 / 0

[JBoss JIRA] (AS7-5075) Local ejb calls are always anonymous

by Michael Gronau (JIRA)

Michael Gronau created AS7-5075: ----------------------------------- Summary: Local ejb calls are always anonymous Key: AS7-5075 URL: https://issues.jboss.org/browse/AS7-5075 Project: Application Server 7 Issue Type: Bug Components: EJB Affects Versions: 7.1.2.Final (EAP) Reporter: Michael Gronau Assignee: jaikiran pai Calling an ejb from within a mbean service for example is always running under 'anonymous' user even with a JAAS login before the invocation. Debugging has shown that only a correct security context is created by the SimpleSecurityManager when the call comes from a remote client. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
8
0 / 0

[JBoss JIRA] Created: (JBAS-5900) jars are not loaded from the lib directory of a sar in JBoss AS 5

by Matt Wringe (JIRA)

jars are not loaded from the lib directory of a sar in JBoss AS 5 ----------------------------------------------------------------- Key: JBAS-5900 URL: https://jira.jboss.org/jira/browse/JBAS-5900 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-5.0.0.CR2 Reporter: Matt Wringe Assignee: Scott M Stark Attachments: testsar.tar.gz In JBoss AS 5, any jars placed in the lib directory of a sar are not loaded and results in a class not found exception. The classes are loaded if the jar is placed in the root directory of the sar. On previous versions of JBoss AS, the classes would be loaded from either location. This prevents sars that would have worked on JBoss AS 4 to fail on JBoss AS 5. Steps to reproduce: 1) take zip attached to this report. 2) deploy test-in-lib.sar to JBoss AS 5. The sar will not deploy and will fail with a classNotFoundException 3) deploy test-in-lib.sar to JBoss AS 4, the sar will deploy without issue. test-in-root.sar will work on both versions of JBoss. The only difference between these sars is the location of the jar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

5
9
0 / 0

[JBoss JIRA] (AS7-3854) MimeMappingAdd and MimeMappingRemove don't affect the runtime

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-3854: ------------------------------------- Summary: MimeMappingAdd and MimeMappingRemove don't affect the runtime Key: AS7-3854 URL: https://issues.jboss.org/browse/AS7-3854 Project: Application Server 7 Issue Type: Bug Components: Domain Management, Web Reporter: Brian Stansberry Assignee: Tomaz Cerar Fix For: 7.1.1.Final While reviewing https://github.com/jbossas/jboss-as/pull/1549 I see that MimeMappingAdd and MimeMappingRemove just update the model but have no effect on the runtime services. If context.isNormalServer() == true, they should either impact a runtime service or put the server into reload-required. Note that the current behavior may make sense during boot if the overall subsystem design has a parent resource adding a Stage.RUNTIME handler that reads child resources and uses their state to set up runtime services. But it's definitely not correct if these operations are performed independently. As part of processing pull request 1549 I'll add TODO comments in these classes referencing this JIRA. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
4
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 June 2012