July 2012 - jboss-jira - Jboss List Archives

[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

13 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

13 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

13 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

13 years, 5 months

5
5
0 / 0

[JBoss JIRA] (AS7-4955) JMS Queues created by the Web admin are not durable by default

by Jeff Mesnil (JIRA)

Jeff Mesnil created AS7-4955: -------------------------------- Summary: JMS Queues created by the Web admin are not durable by default Key: AS7-4955 URL: https://issues.jboss.org/browse/AS7-4955 Project: Application Server 7 Issue Type: Bug Components: Console Affects Versions: 7.1.2.Final (EAP) Reporter: Jeff Mesnil Assignee: Heiko Braun 1. go to http://localhost:9990/console/App.html#messaging 2. click on "Add" button in Queues or Topic tab => the durable checkbox is not checked while the jms-queue model specifies that a queue is durable by default -- 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, 5 months

3
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

13 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

13 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

13 years, 5 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

13 years, 5 months

1
3
0 / 0

[JBoss JIRA] (AS7-5150) Stack overflow with @Produces and @Inject in one ManagedBean

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-5150: ----------------------------------- Summary: Stack overflow with @Produces and @Inject in one ManagedBean Key: AS7-5150 URL: https://issues.jboss.org/browse/AS7-5150 Project: Application Server 7 Issue Type: Bug Components: CDI / Weld Reporter: Thomas Diesler Assignee: Stuart Douglas This code {code} @ManagedBean public class SimpleManagedBean { @Inject List<String> providers; @Produces public List<String> getPaymentProviders() { return Arrays.asList("Visa", "Paypal"); } } {code} lead to {code} 10:36:19,441 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/simple].[SimpleBeanServlet]] (http-/127.0.0.1:8080-1) Allocate exception for servlet SimpleBeanServlet: java.lang.StackOverflowError at org.jboss.weld.manager.BeanManagerImpl.getId(BeanManagerImpl.java:932) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.manager.BeanManagerImpl.hashCode(BeanManagerImpl.java:855) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at java.util.HashMap.get(HashMap.java:300) [rt.jar:1.6.0_33] at org.jboss.weld.util.BeansClosure.getClosure(BeansClosure.java:59) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.manager.BeanManagerImpl.getMostSpecializedBean(BeanManagerImpl.java:979) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:626) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:703) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:136) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:686) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:695) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:161) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:157) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:131) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:153) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:293) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:637) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.AbstractReceiverBean.getReceiver(AbstractReceiverBean.java:77) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.AbstractProducerBean$AbstractProducer.produce(AbstractProducerBean.java:317) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:307) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:637) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:703) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:136) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:686) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:695) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:161) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:157) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:131) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:153) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:293) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:68) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:637) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.AbstractReceiverBean.getReceiver(AbstractReceiverBean.java:77) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] at org.jboss.weld.bean.AbstractProducerBean$AbstractProducer.produce(AbstractProducerBean.java:317) [weld-core-1.1.8.Final.jar:2012-04-29 10:45] {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

13 years, 5 months

2
1
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 July 2012