November 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5950) Streamline :read-resource-description

by Heiko Braun (JIRA)

Heiko Braun created AS7-5950: -------------------------------- Summary: Streamline :read-resource-description Key: AS7-5950 URL: https://issues.jboss.org/browse/AS7-5950 Project: Application Server 7 Issue Type: Feature Request Components: Domain Management Reporter: Heiko Braun Assignee: Brian Stansberry Fix For: 7.2.0.CR1 We have a need for a streamlined read-resource-description operation response. In many cases we only need the attribute descriptions and from those descriptions only a subset of the meta data available. For instance: {noformat} "enable-statistics" => { "type" => BOOLEAN, "description" => "Whether statistics should be enabled.", "expressions-allowed" => true, "nillable" => true, "default" => false, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "all-services" } {noformat} Clients that require information about the structure don't need: - access-type - storage - restart-required In many cases we don't even need - operations - children Would it be possible to further parametrize the read-resource-description operation to allow these distinctions? This would help to reduce the overall payload size when clients communicate with the DC and improve thus improve the overall performance. Not to mention parsing greatly benefits from a streamlined model as well. -- 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, 1 month

1
1
0 / 0

[JBoss JIRA] (AS7-5949) allow custom-formatter configuration

by Aleksandar Kostadinov (JIRA)

Aleksandar Kostadinov created AS7-5949: ------------------------------------------ Summary: allow custom-formatter configuration Key: AS7-5949 URL: https://issues.jboss.org/browse/AS7-5949 Project: Application Server 7 Issue Type: Feature Request Components: Logging Affects Versions: 7.1.3.Final (EAP) Reporter: Aleksandar Kostadinov Assignee: James Perkins Currently only *org.jboss.logmanager.formatters.PatternFormatter* is supported in JBoss AS7 configuration. It would be very useful to allow specifying a custom-formatter (e.g *java.util.logging.XMLFormatter*). At the moment one can specify another formatter in logging.properties but once the logging subsystem is initialized, the settings in logging.properties get overridden. A workaround would be to disable logging subsystem but that has drawbacks. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] (AS7-5943) StandardConfigsXMLValidationUnitTestCase cannot find jboss-common_6_0.xsd on IBM JDK

by Ivo Studensky (JIRA)

Ivo Studensky created AS7-5943: ---------------------------------- Summary: StandardConfigsXMLValidationUnitTestCase cannot find jboss-common_6_0.xsd on IBM JDK Key: AS7-5943 URL: https://issues.jboss.org/browse/AS7-5943 Project: Application Server 7 Issue Type: Bug Components: Test Suite Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1 Environment: IBM JDK IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr9-20110203_74623 (JIT enabled, AOT enabled) IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 20120809_118929 (JIT enabled, AOT enabled) Reporter: Ivo Studensky Assignee: Ivo Studensky StandardConfigsXMLValidationUnitTestCase fails on IBM JDK since it cannot find jboss-common_6_0.xsd schema, see the snippet below for more details. The failure is triggered by invocation of StandardConfigsXMLValidationUnitTestCase#DEFAULT_RESOURCE_RESOLVER.resolveResource() method with systemId == 'http://www.jboss.org/j2ee/schema/jboss-common_6_0.xsd' which is missing in a NAMESPACE_MAP field. Furthermore, compared to Oracle JDK the resolveResource method is invoked with different parameters on IBM JDK, i.e. it loads different XSD's into the validation of the same XML files. On Oracle JDK it is never asked for jboss-common systemId. That is weird. {noformat} junit.framework.AssertionFailedError: http://www.jboss.org/j2ee/schema/jboss-common_6_0.xsd not found at junit.framework.Assert.fail(Assert.java:50) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertNotNull(Assert.java:218) at org.jboss.as.test.smoke.subsystem.xml.AbstractValidationUnitTest.discoverXsd(AbstractValidationUnitTest.java:208) at org.jboss.as.test.smoke.subsystem.xml.AbstractValidationUnitTest$2.resolveResource(AbstractValidationUnitTest.java:124) at org.apache.xerces.util.DOMEntityResolverWrapper.resolveEntity(Unknown Source) at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.resolveSchema(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source) at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(Unknown Source) at org.jboss.as.test.smoke.subsystem.xml.StandardConfigsXMLValidationUnitTestCase.parseXml(StandardConfigsXMLValidationUnitTestCase.java:150) at org.jboss.as.test.smoke.subsystem.xml.StandardConfigsXMLValidationUnitTestCase.testHostSlave(StandardConfigsXMLValidationUnitTestCase.java:82) {noformat} -- 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, 1 month

2
7
0 / 0

[JBoss JIRA] (AS7-5758) Safari digest authentication problem

by Heiko Braun (JIRA)

Heiko Braun created AS7-5758: -------------------------------- Summary: Safari digest authentication problem Key: AS7-5758 URL: https://issues.jboss.org/browse/AS7-5758 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.2.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, 1 month

4
33
0 / 0

[JBoss JIRA] (JBWEB-255) ExtensionValidator does not close inputstream

by James Livingston (JIRA)

James Livingston created JBWEB-255: -------------------------------------- Summary: ExtensionValidator does not close inputstream Key: JBWEB-255 URL: https://issues.jboss.org/browse/JBWEB-255 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossWeb-2.1.11.GA Reporter: James Livingston Assignee: Remy Maucherat ExtensionValidator.validateExtension() closes the InputStream for the web application's manifest, but does not do so for the manifests from jar files. This results in file descriptors being left open until the next garbage collection finalises them. While deploying applications with many jar files, this can result in errors because the file descriptor limit has been reached. This is already fixed in Tomcat 7, and backporting the patch at http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalin... is simple. -- 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, 1 month

2
3
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, 1 month

8
31
0 / 0

[JBoss JIRA] (AS7-5945) FreeBSD isThreadCpuTimeSupported

by Alexis Yerenkow (JIRA)

Alexis Yerenkow created AS7-5945: ------------------------------------ Summary: FreeBSD isThreadCpuTimeSupported Key: AS7-5945 URL: https://issues.jboss.org/browse/AS7-5945 Project: Application Server 7 Issue Type: Feature Request Environment: FreeBSD 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 02:52:29 UTC 2012 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 openjdk6/openjdk7 Reporter: Alexis Yerenkow Platform Tests should be modified, since it's not respecting when isThreadCpuTimeSupported = false (It continues run some test with isThreadCpuTimeSupported, which produces Exceptions, and all test failed); Simple test: ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean(); System.out.println("threadMXBean.isThreadCpuTimeSupported() = " + threadMXBean.isThreadCpuTimeSupported()); System.out.println("threadMXBean.isThreadCpuTimeEnabled() = " + threadMXBean.isThreadCpuTimeEnabled()); Result: threadMXBean.isThreadCpuTimeSupported() = false Exception in thread "main" java.lang.UnsupportedOperationException: Thread CPU time measurement is not supported at sun.management.ThreadImpl.isThreadCpuTimeEnabled(ThreadImpl.java:98) at Test.main(Test.java:19) -- 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, 1 month

2
2
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, 1 month

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, 1 month

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

12 years, 1 month

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2012