April 2012 - jboss-jira - Jboss List Archives

[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

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

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

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

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

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

12 years, 2 months

6
67
0 / 0

[JBoss JIRA] (AS7-4528) Logging subsystem should invoke Handler.close() on shutdown/removal.

by James Perkins (JIRA)

James Perkins created AS7-4528: ---------------------------------- Summary: Logging subsystem should invoke Handler.close() on shutdown/removal. Key: AS7-4528 URL: https://issues.jboss.org/browse/AS7-4528 Project: Application Server 7 Issue Type: Bug Components: Logging Reporter: James Perkins Assignee: James Perkins Fix For: 7.1.2.Final-redhat1 Currently the subsystem removal just uses the ReloadRequiredRemoveStepHandler.INSTANCE. A custom OSH should be used to invoke the close method on handlers when the subsystem is removed. -- 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

12 years, 2 months

1
3
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

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

12 years, 2 months

6
15
0 / 0

[JBoss JIRA] (JBRULES-3283) Concurrency issue: Invalid bytecode generated by KnowledgeBuilder.add()

by Thomas Kruse (Created) (JIRA)

Concurrency issue: Invalid bytecode generated by KnowledgeBuilder.add() ----------------------------------------------------------------------- Key: JBRULES-3283 URL: https://issues.jboss.org/browse/JBRULES-3283 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.3.0.Final, 5.3.0.CR1 Environment: Oracle Java 6, Oracle Java 7, Linux, MacOS java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03-384-10M3425) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-384, mixed mode) Reporter: Thomas Kruse Assignee: Mark Proctor Priority: Minor Since Drools 5.3.0.CR1 concurrent creation of different knowledgebases from filesystem DRL rule definition leads to illegal bytecode. Reproduceable with Janino and eclipse compiler. I have a maven based test project which executes the unit tests in parallel, this is the result: {code} runFirst(de.trion.drools53.TwoTest): -1 runFirst(de.trion.drools53.FourTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Expecting to find integer on stack runSecond(de.trion.drools53.FourTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Expecting to find integer on stack runFirst(de.trion.drools53.OneTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Expecting to find integer on stack runFirst(de.trion.drools53.ThreeTest): (class: de/trion/drools53/Rule_When_a_user_is_young__print_his_name_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Incompatible object argument for function call runSecond(de.trion.drools53.ThreeTest): (class: de/trion/drools53/Rule_When_there_is_god__the_light_always_shines_DefaultConsequenceInvoker, method: equals signature: (Ljava/lang/Object;)Z) Unable to pop operand off an empty stack {code} Workaround: synchronize access Not affected: Drools 5.3.0.Beta -- 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

12 years, 2 months

6
12
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2012