March 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-2792) CLI doesn't show resolved multicast address for socket-binding definition like jgroups-udp or jgroups-mping

by Rostislav Svoboda (Created) (JIRA)

CLI doesn't show resolved multicast address for socket-binding definition like jgroups-udp or jgroups-mping ----------------------------------------------------------------------------------------------------------- Key: AS7-2792 URL: https://issues.jboss.org/browse/AS7-2792 Project: Application Server 7 Issue Type: Bug Components: CLI, Domain Management Affects Versions: 7.1.0.Beta1 Reporter: Rostislav Svoboda Assignee: Alexey Loubyansky Fix For: 7.1.0.CR1 Hi Alexey. CLI doesn't show resolved multicast address for socket-binding definition like jgroups-udp or jgroups-mping. I would expect to see 'resolved-multicast-address' or something similar to 'resolved-address' for interface definition. I hope management model can provide such information. If not please reassign to Brian. {code} $ bin/standalone.sh -c standalone-ha.xml -u 224.34.3.154 $ bin/jboss-admin.sh -c [standalone@localhost:9999 /] cd /socket-binding-group=standard-sockets/socket-binding=jgroups-udp [standalone@localhost:9999 socket-binding=jgroups-udp] :read-resource(include-runtime=true) { "outcome" => "success", "result" => { "bound" => false, "bound-address" => undefined, "bound-port" => undefined, "fixed-port" => false, "interface" => undefined, "multicast-address" => expression "${jboss.default.multicast.address:230.0.0.4}", "multicast-port" => 45688, "name" => "jgroups-udp", "port" => 55200 } } {code} -- 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

11 years, 5 months

6
8
0 / 0

[JBoss JIRA] (AS7-3571) Console should allow setting multiple JNDI names for JMS queues/topics

by Jan Martiska (JIRA)

Jan Martiska created AS7-3571: --------------------------------- Summary: Console should allow setting multiple JNDI names for JMS queues/topics Key: AS7-3571 URL: https://issues.jboss.org/browse/AS7-3571 Project: Application Server 7 Issue Type: Feature Request Components: Console Affects Versions: 7.1.0.CR1b Reporter: Jan Martiska Assignee: Heiko Braun Priority: Optional Fix For: 7.1.1.Final The model and CLI allow setting multiple JNDI names for JMS resources. In the admin console, only one name is possible. Also, it is currently not possible to change the name after the resource is created. -- 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

11 years, 5 months

4
10
0 / 0

[JBoss JIRA] Created: (AS7-1264) Add schema references to standalone.xml, domain.xml, host.xml

by Gerry Matte (JIRA)

Add schema references to standalone.xml, domain.xml, host.xml ------------------------------------------------------------- Key: AS7-1264 URL: https://issues.jboss.org/browse/AS7-1264 Project: Application Server 7 Issue Type: Task Components: Domain Management Affects Versions: 7.0.0.CR1 Reporter: Gerry Matte Assignee: Brian Stansberry It appears that users of Jboss 7 will be often modifying these configuration files as they fine tune their server and when they discover how to implement new features. It seems quite surprising to me that these files do not have the schema references identified in the file header. Any good XML editor would use those references to validate changes and new entries and thereby avoid a great deal of frustration for users and those who provide support for forum issues. I realise that if jboss validated each xml file when starting up there would be performance penalty that may be unacceptable to many users. A command-line switch could be used to either turn on xml validation (if the default were that no validation is performed) or conversely to turn off xml validation if the default state was that xml validation was on. Personally I favor having a switch that turns off validation - to be used on production servers only. If the schema/dtd files were published online and referenced within the configuration xml files, future changes to the schema structure would be "enforced" upon the user community as they attemted to use an out-of-date version when upgrading to a new version of Jboss 7. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

7
13
0 / 0

[JBoss JIRA] (AS7-3713) JBoss Web module.xml declares clustering sso as optional, when it is instead required

by Tristan Tarrant (JIRA)

Tristan Tarrant created AS7-3713: ------------------------------------ Summary: JBoss Web module.xml declares clustering sso as optional, when it is instead required Key: AS7-3713 URL: https://issues.jboss.org/browse/AS7-3713 Project: Application Server 7 Issue Type: Bug Components: Web Affects Versions: 7.1.0.Final Reporter: Tristan Tarrant Assignee: Remy Maucherat org/jboss/as/web/main/module.xml contains <module name="org.jboss.as.clustering.web.spi" optional="true"/>, but the clustering classes are imported directly by WebVirtualHostAdd.java, so the optional is kind of required :) -- 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

11 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (AS7-1547) Problem starting jboss 7 with Java Service Wrapper

by andrei povodyrev (JIRA)

Problem starting jboss 7 with Java Service Wrapper -------------------------------------------------- Key: AS7-1547 URL: https://issues.jboss.org/browse/AS7-1547 Project: Application Server 7 Issue Type: Bug Components: Logging Affects Versions: 7.0.0.Final Environment: Red Hat, Windows 7 Reporter: andrei povodyrev Assignee: David Lloyd Fix For: Open To Community Problem starting jboss 7 with Java Service Wrapper We tried to upgrade Java Service Wrapper (JSW) configuration from Jboss 5 to Jboss 7. Jboss fails to start with these messages WARNING: Failed to load the specified logmodule org.jboss.logmanager:main followed by IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager") Software: Jboss-as-7.0.0-Final wrapper-windows-x86-64-3.5.10-st (Java Service Wrapper win 64 distribution) Issue: org.jboss.modules.Main generates the warning as LogManager is already initialized to java.util.logging.LogManager by the Wrapper. With jboss 7 org.jboss.logmanager.LogManager is required. Per LogManager design only one instance may exist in jvm. jboss 7 assume that it is the first in line to initialize java.util.logger.LogManager. Wrapper is the one who inits LogManager first (thus triggering primordial configuration initialization). Jboss then fails to start since it requiresits own logging implementation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

5
5
0 / 0

[JBoss JIRA] (AS7-3934) Provide modcluster runtime operation within console

by Heiko Braun (JIRA)

Heiko Braun created AS7-3934: -------------------------------- Summary: Provide modcluster runtime operation within console Key: AS7-3934 URL: https://issues.jboss.org/browse/AS7-3934 Project: Application Server 7 Issue Type: Task Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.1.2.Final -- 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

11 years, 5 months

1
4
0 / 0

[JBoss JIRA] (AS7-2213) Provide an operation to retrieve the last 10 errors form the log

by Heiko Braun (Created) (JIRA)

Provide an operation to retrieve the last 10 errors form the log ---------------------------------------------------------------- Key: AS7-2213 URL: https://issues.jboss.org/browse/AS7-2213 Project: Application Server 7 Issue Type: Feature Request Components: Domain Management Reporter: Heiko Braun Assignee: Brian Stansberry Fix For: 7.1.0.CR1 -- 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

11 years, 5 months

8
31
0 / 0

[JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency

by Nikita Tovstoles (JIRA)

Nikita Tovstoles created JASSIST-163: ---------------------------------------- Summary: RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency Key: JASSIST-163 URL: https://issues.jboss.org/browse/JASSIST-163 Project: Javassist Issue Type: Enhancement Affects Versions: 3.16.1-GA, 3.15.0-GA Environment: hibernate-core 3.6.10.Final Reporter: Nikita Tovstoles Assignee: Shigeru Chiba We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by ProxyFactory.createClass()). In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods: {code} synchronized (methods) { if (methods[index] == null) { methods[index + 1] = thisMethod == null ? null : findMethod(self, thisMethod, desc); methods[index] = findSuperMethod(self, superMethod, desc); } } {code} Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead repeatedly executing the above synchronized statement. Full [YourKit profiler|http://yourkit.com] is attached, salient screen shots also attached separately -- 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

11 years, 5 months

6
67
0 / 0

[JBoss JIRA] Created: (AS7-1833) CLI usability: operation :shutdown results in "Communication error"

by Radoslav Husar (JIRA)

CLI usability: operation :shutdown results in "Communication error" ------------------------------------------------------------------- Key: AS7-1833 URL: https://issues.jboss.org/browse/AS7-1833 Project: Application Server 7 Issue Type: Enhancement Components: CLI Affects Versions: 7.0.1.Final, 7.0.0.Final Reporter: Radoslav Husar Assignee: Alexey Loubyansky Priority: Minor If you shutdown the server, you get an error: {code} [standalone@localhost:9999 /] :shutdown Communication error: Channel closed Closed connection to localhost:9999 {code} Even though its considered by this comment clean - https://issues.jboss.org/browse/AS7-689?focusedCommentId=12614756&page=co... - I is not really clean as you get an error but termination of the channel can be anticipated. Users might be confused now knowing if its an actual error or not. For example take a look at SSH. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

6
10
0 / 0

[JBoss JIRA] Created: (JBAS-9203) EJBAccessException dont contains my LoginException thrown in a custom LoginModule during login-Method

by Felix Ullrich (JIRA)

EJBAccessException dont contains my LoginException thrown in a custom LoginModule during login-Method ----------------------------------------------------------------------------------------------------- Key: JBAS-9203 URL: https://issues.jboss.org/browse/JBAS-9203 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: 6.0.0.Final Reporter: Felix Ullrich Assignee: Anil Saldhana This problem was already mentioned here: [http://community.jboss.org/message/114379] A thrown LoginException in a custom LoginModule is not correctly wrapped into the javax.ejb.EJBAccessException on client-side. The cause of EJBAccessException is just not set - its null... The RemoteClient-Code looks like this try { ejb.someMethod(); } catch (final EJBAccessException e) { e.printStackTrace(); throw e.getCause(); } and the Stacktrace: javax.ejb.EJBAccessException: Invalid User at org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:161) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.stateful.StatefulContainer.dynamicInvoke(StatefulContainer.java:603) at org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53) at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91) at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:898) at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:791) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:744) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:548) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:234) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:216) at org.jboss.remoting.Client.invoke(Client.java:1961) at org.jboss.remoting.Client.invoke(Client.java:804) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.async.impl.interceptor.AsynchronousClientInterceptor.invoke(AsynchronousClientInterceptor.java:143) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62) at $Proxy8.invoke(Unknown Source) at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:185) at $Proxy7.findAll(Unknown Source) at RemoteClient.main(RemoteClient.java:22) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.ejb3.async.impl.interceptor.AsynchronousClientInterceptor.invoke(AsynchronousClientInterceptor.java:143) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) at org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62) at $Proxy8.invoke(Unknown Source) at org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:185) at $Proxy7.findAll(Unknown Source) at RemoteClient.main(RemoteClient.java:22) Exception in thread "main" java.lang.NullPointerException at RemoteClient.main(RemoteClient.java:25) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 5 months

6
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2012