October 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5127) Performance bottleneck on Javassist

by Alessandro Lazarotti (JIRA)

Alessandro Lazarotti created AS7-5127: ----------------------------------------- Summary: Performance bottleneck on Javassist Key: AS7-5127 URL: https://issues.jboss.org/browse/AS7-5127 Project: Application Server 7 Issue Type: Bug Components: JPA / Hibernate Affects Versions: 7.1.2.Final (EAP) Environment: Sun/Oracle JDK 1.6_32, Linux 64b Reporter: Alessandro Lazarotti Assignee: Scott Marlow Fix For: No Release The method javassist.util.proxy.RuntimeSupport.find2methods has a synch block, called indirectly by ProxyFactory.createClass(). It is a strong bottleneck for frameworks as Hibernate which can use it several times in a large set of data. Javassist 3.17.0-GA fixes it. AS7 should update its current javassist version. More details in https://issues.jboss.org/browse/JASSIST-163 -- 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
6
0 / 0

[JBoss JIRA] (JBRULES-3456) Eclipse drools plugin - drools jars dissappear from drools library when internal classes are switched from Discouraged to Accesible

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3456: ------------------------------------ Summary: Eclipse drools plugin - drools jars dissappear from drools library when internal classes are switched from Discouraged to Accesible Key: JBRULES-3456 URL: https://issues.jboss.org/browse/JBRULES-3456 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When I set Drools internal classes from Discouraged to Accessible in Eclipse, then the jars dissapear from Drools library in Library screen of project. I have thought that setting internal classes to Accesible would remove several warnings from our test suite, but actual result is that there is just Drools library which is without jars. -- 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
15
0 / 0

[JBoss JIRA] (AS7-5449) when defining custom executor for connector thread priority is not optional

by Mathieu Lachance (JIRA)

Mathieu Lachance created AS7-5449: ------------------------------------- Summary: when defining custom executor for connector thread priority is not optional Key: AS7-5449 URL: https://issues.jboss.org/browse/AS7-5449 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.2.Final (EAP) Reporter: Mathieu Lachance when defining a custom executor in the threads subsystem for the connector defined in the web subsystem like : {code:xml} <subsystem xmlns="urn:jboss:domain:threads:1.1"> <thread-factory name="ConnectorThreadFactory" group-name="ConnectorThreadPool"/> <unbounded-queue-thread-pool name="ConnectorThreadPool"> <max-threads count="500"/> <keepalive-time time="60" unit="seconds"/> <thread-factory name="ConnectorThreadFactory"/> </unbounded-queue-thread-pool> </subsystem> <subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false"> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp" redirect-port="8443" executor="ConnectorThreadPool"/> </subsystem> {code} it will fail with : {quote} 17:19:06,508 ERROR [org.apache.tomcat.util.net.JIoEndpoint] (http-/0.0.0.0:8443-Acceptor-0) Error allocating socket processor: java.lang.IllegalArgumentException at java.lang.Thread.setPriority(Thread.java:1058) [rt.jar:1.6.0_31] at org.jboss.threads.JBossThreadFactory.createThread(JBossThreadFactory.java:127) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] at org.jboss.threads.JBossThreadFactory.newThread(JBossThreadFactory.java:101) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] at java.util.concurrent.ThreadPoolExecutor.addThread(ThreadPoolExecutor.java:672) [rt.jar:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(ThreadPoolExecutor.java:697) [rt.jar:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:652) [rt.jar:1.6.0_31] at org.jboss.threads.JBossThreadPoolExecutor.execute(JBossThreadPoolExecutor.java:63) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] at org.jboss.threads.DelegatingBlockingExecutorService.execute(DelegatingBlockingExecutorService.java:42) [jboss-threads-2.0.0.GA.jar:2.0.0.GA] at org.jboss.as.threads.ManagedExecutorService.execute(ManagedExecutorService.java:64) [jboss-as-threads-7.1.2.Final.jar:7.1.2.Final] at org.apache.tomcat.util.net.JIoEndpoint.processSocket(JIoEndpoint.java:1237) [jbossweb-7.0.16.Final.jar:] at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:325) [jbossweb-7.0.16.Final.jar:] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31] {quote} even though if documentation state that thread priority is optional : {code:xml} <xs:complexType name="thread-factory"> <xs:annotation> <xs:documentation> <![CDATA[ A thread factory (implementing java.util.concurrent.ThreadFactory). The "name" attribute is the bean name of the created thread factory. The optional "priority" attribute may be used to specify the thread priority of created threads. The optional "group-name" attribute specifies the name of a the thread group to create for this thread factory. The "thread-name-pattern" is the template used to create names for threads. The following patterns may be used: %% - emit a percent sign %t - emit the per-factory thread sequence number %g - emit the global thread sequence number %f - emit the factory sequence number %i - emit the thread ID %G - emit the thread group name ]]> </xs:documentation> </xs:annotation> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="group-name" type="xs:string" use="optional"/> <xs:attribute name="thread-name-pattern" type="xs:string" use="optional"/> <xs:attribute name="priority" type="priority" use="optional"/> </xs:complexType> {code} -- 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

11 years, 5 months

3
9
0 / 0

[JBoss JIRA] Created: (JBAS-7882) Wrong provider code base for security provider included in packed ear

by Petr H (JIRA)

Wrong provider code base for security provider included in packed ear --------------------------------------------------------------------- Key: JBAS-7882 URL: https://jira.jboss.org/jira/browse/JBAS-7882 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: VFS Affects Versions: JBossAS-6.0.0.M2, JBossAS-5.1.0.GA Environment: Any OS, JDK 5 and 6, JBoss AS 5.1.0 and 6.0.0.M2 Reporter: Petr H We've got applications which uses the IAIK JCE provider (http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/JCA-JCE) whose library is included directly in our application. On JBoss AS 5 and later, we can't use this provider as usually. The new VFS mechanism seems to break the path determination to the IAIK provider library (needed to determine provider code base) - it still points into the ear/war structure inside the server deploy directory but as all this is packed into one ear file, the provider verification.fails because of unsigned ear/war and thus the following exception is thrown: 2010-04-01 15:04:20,890 ERROR [STDERR] (http-0.0.0.0-8180-1) java.lang.SecurityException: JCE cannot authenticate the provider IAIK 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.Cipher.getInstance(DashoA13*..) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at iaik.test.ControllerServlet.service(ControllerServlet.java:123) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:905) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:592) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2036) 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) at java.lang.Thread.run(Thread.java:619) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) Caused by: java.util.jar.JarException: Cannot parse jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_c.a(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.b(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) at javax.crypto.SunJCE_b.a(DashoA13*..) 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) ... 24 more This works when one of tho three mentioned workarounds is used. The most interesting of course is the third workaround for which the code base corectly points to the temporary IAIK library instance in the java.io.tmpdir: 2010-04-01 15:09:51,291 INFO [STDOUT] (http-0.0.0.0-8180-1) Provider code base: file:/tmp/nestedjar2481829661547119990.tmp I'll attach a simple testcase ear (IAIKTest.ear) which contains an evaluation version of IAIK provider library (thanks for permission to the IAIK authors) and a simple servlet (including source) which demonstrates the problem. All you need to do is to have the unrestricted JCE policy files installed in your JRE and then just put the IAIKTest.ear into the deploy directory, start the JBoss instance and access the test servlet URL in browser, for example: http://localhost:8080/IAIKTestWeb/ControllerServlet On init (which happens on start) it will register the IAIK provider On service (after you access it in browser) it will attempt to get some cipher instance and here it fails. I'll also attach two log files covering the problem: - server-default.log with default server setup where the issue occurs - server-forceVfsJar.log with jboss.vfs.forceVfsJar=true where the issue doesn't occur Also I think this is more generic problem because we had similar issues, where some jar or resource location was pointing to the packed ear/war structure inside the deploy directory instead of those VFS temporary locations, with our own code (when attemting to obtain full path) and had to perform some modifications in order to make it working. The same set of workarounds could resolve these issues as well. -- 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

11 years, 5 months

17
51
0 / 0

[JBoss JIRA] (AS7-5293) Align domain.sh and standalone.sh logic about adding -server

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-5293: ------------------------------------- Summary: Align domain.sh and standalone.sh logic about adding -server Key: AS7-5293 URL: https://issues.jboss.org/browse/AS7-5293 Project: Application Server 7 Issue Type: Sub-task Components: Scripts Reporter: Brian Stansberry Fix For: 7.2.0.CR1, Open To Community The domain.sh script has a number of JVM vendor checks it uses to decide whether to add -server to the jvm launch command. In standalone.sh it's simpler; it simply checks for OSX. I can't see any reason this logic should be significantly different between the two cases, either the JVM vendor checks are needed in both or they aren't needed in either. -- 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
1
0 / 0

[JBoss JIRA] Created: (JASSIST-126) create OSGi bundle information

by Mark Struberg (JIRA)

create OSGi bundle information ------------------------------ Key: JASSIST-126 URL: https://jira.jboss.org/browse/JASSIST-126 Project: Javassist Issue Type: Feature Request Affects Versions: 3.12.0.GA Reporter: Mark Struberg Assignee: Shigeru Chiba Fix For: 3.13.0.GA Create OSGi bundle information for javassist at build time. -- 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

11 years, 5 months

5
9
0 / 0

[JBoss JIRA] (AS7-5738) JNDI View doesn't work in domain mode

by Heiko Braun (JIRA)

Heiko Braun created AS7-5738: -------------------------------- Summary: JNDI View doesn't work in domain mode Key: AS7-5738 URL: https://issues.jboss.org/browse/AS7-5738 Project: Application Server 7 Issue Type: Feature Request Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.2.0.CR1 Yields an exception on the server side: {noformat} [Server:server-one] Caused by: java.lang.ClassNotFoundException: javax.management.j2ee.ManagementHome from [Module "org.jboss.as.naming:main" from local module loader @e49d67c (roots: /Users/hbraun/dev/prj/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules)] [Server:server-one] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.1.3.GA] [Server:server-one] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.1.3.GA] [Server:server-one] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.1.3.GA] [Server:server-one] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) [jboss-modules.jar:1.1.3.GA] [Server:server-one] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.1.3.GA] {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

11 years, 5 months

2
1
0 / 0

[JBoss JIRA] (AS7-4532) fix jvm management model for server and groups

by Emanuel Muckenhuber (JIRA)

Emanuel Muckenhuber created AS7-4532: ---------------------------------------- Summary: fix jvm management model for server and groups Key: AS7-4532 URL: https://issues.jboss.org/browse/AS7-4532 Project: Application Server 7 Issue Type: Bug Components: Domain Management Affects Versions: 7.1.0.Final, 7.0.0.Final Reporter: Emanuel Muckenhuber Fix For: 7.2.0.Alpha1 We need to update the JVM child resource definition for server-groups and servers to only allow a single JVM configuration (i.e. configuration=JVM) resource. Currently only the first configured VM is used, where the name is the reference to the corresponding host level JVM. -- 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] (AS7-3463) Provide Unit for JVM configuration elements

by Heiko Braun (JIRA)

Heiko Braun created AS7-3463: -------------------------------- Summary: Provide Unit for JVM configuration elements Key: AS7-3463 URL: https://issues.jboss.org/browse/AS7-3463 Project: Application Server 7 Issue Type: Feature Request Components: Domain Management Reporter: Heiko Braun Assignee: Brian Stansberry Fix For: 7.2.0.Alpha1 Like with any other config element, units for the JVM parameters would nice. I.e. instead of encoding it into the string value ("64m") it would be better to split the actual value from unit (value=64, unit=<kb|mb|gb>). See the thread subsystem for a reference how this is done in other places -- 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: (JBAOP-796) Creation of ClassAdvisor must use the AspectManager equivalent to the advised class' ClassLoader

by Flavia Rainone (JIRA)

Creation of ClassAdvisor must use the AspectManager equivalent to the advised class' ClassLoader ------------------------------------------------------------------------------------------------ Key: JBAOP-796 URL: https://jira.jboss.org/browse/JBAOP-796 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.9.Alpha1 Reporter: Flavia Rainone Assignee: Flavia Rainone Fix For: 2.1.6 CP01, 2.1.9.GA, 2.2.1.GA Currently, an Advisor is created by calling AspectManager.instance().getAdvisor(). The correct is to create the advisor by calling AspectManager.instance(WovenClass.class).getAdvisor(WovenClass.class). Otherwise, the Advisor will be created as part of the AspectManager/Domain corresponding to the current context class loader: public static synchronized AspectManager instance() { return instance(Thread.currentThread().getContextClassLoader()); } In the JBoss AS environment, if the woven class is loaded during an archive deployment, this is equivalent to say that the Advisor will be erroneously created by the domain of the current deployment, instead of being created by the appropriate AspectManager/Domain instance. -- 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

11 years, 5 months

2
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2012