January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2764) Performance degradation from 4.0.7 to 5.0.1 to 5.1.0

by David Ward (JIRA)

Performance degradation from 4.0.7 to 5.0.1 to 5.1.0 ---------------------------------------------------- Key: JBRULES-2764 URL: https://jira.jboss.org/browse/JBRULES-2764 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core, drools-core (expert) Affects Versions: 5.1.1.FINAL, 5.0.1.FINAL Reporter: David Ward Assignee: Mark Proctor I have noticed a performance degradation from 4.0.7 to 5.0.1, and 5.0.1 to 5.1.0. Both in creating new StatelessSessions, and executing them. I am attaching a portable test case which shows the degradation. Please refer to the test.zip!/README.txt file for full instructions and explanation. For the purpose of this jira description (and to show the degradation from a high-level), here is sample output. Note that the run*.sh scripts only create new StatelessSessions, but do not execute them. The exec*.sh scripts also execute the StatelessSessions. run407.sh RuleTest: count=10000, total=33ms, average=0.0033ms KnowledgeTest: API not available run501.sh RuleTest: count=10000, total=1147ms, average=0.1147ms KnowledgeTest: count=10000, total=784ms, average=0.0784ms run511.sh RuleTest: count=10000, total=2381ms, average=0.2381ms KnowledgeTest: count=10000, total=2007ms, average=0.2007ms exec407.sh RuleTest: count=10000, total=875ms, average=0.0875ms KnowledgeTest: API not available exec501.sh RuleTest: count=10000, total=2641ms, average=0.2641ms KnowledgeTest: count=10000, total=2223ms, average=0.2223ms exec511.sh RuleTest: count=10000, total=4188ms, average=0.4188ms KnowledgeTest: count=10000, total=3664ms, average=0.3664ms -- 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

15 years, 3 months

2
9
0 / 0

[JBoss JIRA] Created: (JBWEB-194) Build does not produce correct version

by Mike Millson (JIRA)

Build does not produce correct version -------------------------------------- Key: JBWEB-194 URL: https://issues.jboss.org/browse/JBWEB-194 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Affects Versions: JBossWeb-2.1.8.GA Reporter: Mike Millson Assignee: Mike Millson Version properties in build.properties.default are not being maintained: version.major=2 version.minor=1 version.build=4 version.patch=0 version.tag=SNAPSHOT -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8788) Remove duplicate JPA parsing deployer

by Ales Justin (JIRA)

Remove duplicate JPA parsing deployer ------------------------------------- Key: JBAS-8788 URL: https://issues.jboss.org/browse/JBAS-8788 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployers, EJB3 Affects Versions: 6.0.0.Final Reporter: Ales Justin Assignee: Ales Justin Fix For: 6.0.1 There is a duplicate JPA parsing deployer in ejb3-as-deployers-jboss-beans.xml to the one in jpa-deployers-jboss-beans.xml. Removing the one in ejb3-*. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8783) Server fails to start if JAVA_HOME is not set

by Brian Stansberry (JIRA)

Server fails to start if JAVA_HOME is not set --------------------------------------------- Key: JBAS-8783 URL: https://issues.jboss.org/browse/JBAS-8783 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Alpha1 Reporter: Brian Stansberry Priority: Critical Fix For: 7.0.0.Alpha2 If I there is no JAVA_HOME I see the following error and more importantly - the server freezes and can not be stopped unlesss I manually kill -9 the process. Same happens on HEAD. ========================================================================= JBoss Bootstrap Environment JBOSS_HOME: /Users/vladimirralev/Downloads/jboss-7.0.0.Alpha1 JAVA: java JAVA_OPTS: ========================================================================= Cannot run Java in 64 bit mode. Continuing in 32 bit mode. 16:22:08,757 INFO [org.jboss.modules] (main) JBoss Modules version 1.0.0.Beta11 16:22:09,203 INFO [org.jboss.as.process.Server Manager.status] (main) Starting process 'Server Manager' [Server Manager] Cannot run Java in 64 bit mode. Continuing in 32 bit mode. [Server Manager] 16:22:09,589 INFO [org.jboss.modules] (main) JBoss Modules version 1.0.0.Beta11 [Server Manager] 16:22:10,258 INFO [org.jboss.as.domain.controller] (Thread-3) Starting Domain Controller [Server Manager] 16:22:10,322 INFO [org.jboss.as.domain.controller] (Thread-3) Parsing Domain Configuration [Server Manager] 16:22:11,165 INFO [org.jboss.as.server.manager] (Thread-3) Starting server server-three 16:22:11,260 INFO [org.jboss.as.process.Server:server-three.status] (pool-2-thread-2) Starting process 'Server:server-three' 16:22:11,279 ERROR [org.jboss.as.process.Server:server-three.status] (pool-2-thread-2) Failed to start process 'Server:server-three': java.io.IOException: Cannot run program "/Users/vladimirralev/Downloads/jboss-7.0.0.Alpha1/java" (in directory "/Users/vladimirralev/Downloads/jboss-7.0.0.Alpha1"): error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) [:1.6.0_22] at org.jboss.as.process.ManagedProcess.doStart(ManagedProcess.java:151) at org.jboss.as.process.ManagedProcess.start(ManagedProcess.java:129) at org.jboss.as.process.ProcessManager.startProcess(ProcessManager.java:143) at org.jboss.as.process.ProcessManagerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessManagerServerHandler.java:160) at org.jboss.as.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:239) at org.jboss.as.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:198) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_22] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_22] at java.lang.Thread.run(Thread.java:680) [:1.6.0_22] Caused by: java.io.IOException: error=2, No such file or directory at java.lang.UNIXProcess.forkAndExec(Native Method) [:1.6.0_22] at java.lang.UNIXProcess.<init>(UNIXProcess.java:53) [:1.6.0_22] at java.lang.ProcessImpl.start(ProcessImpl.java:91) [:1.6.0_22] at java.lang.ProcessBuilder.start(ProcessBuilder.java:453) [:1.6.0_22] ... 9 more -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBMETA-327) Class-level @Asynchronous processor has inconsistent application of async methods

by Andrew Rubinger (JIRA)

Class-level @Asynchronous processor has inconsistent application of async methods --------------------------------------------------------------------------------- Key: JBMETA-327 URL: https://issues.jboss.org/browse/JBMETA-327 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Components: ejb Affects Versions: jboss-metadata-ejb-2.0.0-alpha-28 Reporter: Andrew Rubinger Fix For: jboss-metadata-ejb-2.0.0-alpha-29 AsyncMethodMetaData needs to be created inside the loop, not out. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2742) Provide an API to access the WorkItem interface outside executeWorkItem()

by Julien Serdaru (JIRA)

Provide an API to access the WorkItem interface outside executeWorkItem() ------------------------------------------------------------------------- Key: JBRULES-2742 URL: https://jira.jboss.org/browse/JBRULES-2742 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-api, drools-core, drools-core (flow) Affects Versions: 5.1.1.FINAL, 5.1.0.FINAL, 5.0.1.FINAL, 5.0.0.FINAL Environment: Any Reporter: Julien Serdaru Assignee: Mark Proctor I had a discussion with Kris about this issue, please find below excerpts of our talks: Julien: When executing workItems synchronously, executeWorkItem() provides access to the WorkItem interface, and with it all the parameters that allow me to complete this task using completeWorkItem(). That is fine and works great. However, when the user decides to complete the task asynchronously (delegating persistence to Drools, whether JPA or memory), there is no way to access the workItem variables before calling completeWorkItem(). Right now I store the workItem variables in my own persisted entity when executeWorkItem() is called. It works, but it just seemed unnatural to duplicate variables that are already stored by Drools, especially when Drools is running on the same platform as the application completing the tasks. In my use case (but I could think of many others), I use Drools in a web container and have a WebTaskHandler workitem implementation configured using workItem parameters. It could be whether a web form is disabled of not, or a list of properties to validate...any variables that I need in order to be able to complete the task. Kris: As long as you understand what I was getting at when I was saying you should be aware you are actually querying our internal data, I do understand that, if you also know that you are actually duplicating information, I understand that you might simply want to reuse that. I don't mind exposing a method like that, although I would prefer it then to be part of an internal api as we call it, as we don't really want this type of functionality being used by most users. Taking a look at the implementation, it seems that the JPAWorkItemManager already has a public WorkItem getWorkItem(id) method. Though it currently is pretty difficult to get your hands on this implementation objects directly, but if I add it to the internal WorkItemManager interface, it should be trivial to access if you cast to that interface. Feel free to open up a JIRA and send me the link and I'll try to take a look at this. -- 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

15 years, 3 months

3
2
0 / 0

[JBoss JIRA] Created: (SECURITY-547) CLONE - org.jboss.security.plugins.FilePassword requires write permission for decoding

by Brad Maxwell (JIRA)

CLONE - org.jboss.security.plugins.FilePassword requires write permission for decoding -------------------------------------------------------------------------------------- Key: SECURITY-547 URL: https://issues.jboss.org/browse/SECURITY-547 Project: PicketBox (JBoss Security and Identity Management) Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.1-BETA1, 2.0.1-BETA2, 2.0.2-BETA3, 2.0.2-BETA4, 2.0.2-BETA5, 2.0.2-BETA6, 2.0.2.Beta7, 2.0.2.CR2, 2.0.2.CR3, 2.0.2.CR4, 2.0.2.CR5, 2.0.2.CR6, 2.0.2.CR7, 2.0.2.CR8 Environment: JBoss AS 4.2.3.GA Reporter: Brad Maxwell Assignee: Marcus Moyses Priority: Minor Fix For: JBossSecurity_2.0.4.SP4, PicketBox_v4_0_alpha3 Attachments: SECURITY-292.patch We use org.jboss.security.plugins.FilePassword to avoid storing passwords in clear text. Once created, we'd like to change the file's permission to read-only for regular users in order to ensure that only trusted users can update it. However, this won't work as the class FilePassword always requires write permission even for decoding the password. The class should be modified so that write permission is only required when create / update the password file. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMDR-72) AnnotatedElementMetaDataLoader doesn't work on bridge methods from parent classes

by James Livingston (JIRA)

AnnotatedElementMetaDataLoader doesn't work on bridge methods from parent classes --------------------------------------------------------------------------------- Key: JBMDR-72 URL: https://issues.jboss.org/browse/JBMDR-72 Project: JBoss MetaData Repository Issue Type: Bug Components: Annotations Affects Versions: JBossMDR-2.2.0.Alpha3, JBossMDR-2.0.2.GA Reporter: James Livingston Attachments: jbmdr-testcase-72.diff JBMDR-69 fixed a bug where it wouldn't detect annotations where there was a bridge method created by implementing a type parameterised interface. The fix for that bug does not work if the method is defined in a parent class rather than the class itself, due to getDeclaredMethods() only returning those declared in the class. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-7499) Package trove license with the AS release build

by Rajesh Rajasekaran (JIRA)

Package trove license with the AS release build ----------------------------------------------- Key: JBAS-7499 URL: https://jira.jboss.org/jira/browse/JBAS-7499 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Build System Affects Versions: JBossAS-6.0.0.M1 Reporter: Rajesh Rajasekaran Assignee: Paul Gier Fix For: JBossAS-6.0.0.M2 Trove is a dependency for AS, but its license which should be packaged for legal reasons is not pulled in by the build. <dependency> <groupId>trove</groupId> <artifactId>trove</artifactId> <version>1.0.2</version> </dependency> License exists here: http://repository.jboss.org/licenses/trove.txt The release build packages all licenses under thirdparty/licenses. This should also contain the license for trove. -- 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

15 years, 3 months

4
4
0 / 0

[JBoss JIRA] Created: (JBLOGGING-53) Slf4jLogger wrong formatting in methods with Object arrays

by Adam Michalik (JIRA)

Slf4jLogger wrong formatting in methods with Object arrays ---------------------------------------------------------- Key: JBLOGGING-53 URL: https://issues.jboss.org/browse/JBLOGGING-53 Project: JBoss Logging Issue Type: Bug Security Level: Public (Everyone can see) Components: jboss-logging-logmanager Affects Versions: 3.0.0.Beta4-jboss-logging Environment: JBoss AS 6.0.0.Final Reporter: Adam Michalik Assignee: David Lloyd Slf4jLogger in JBoss Logging Manager formats the messages in logging methods with Object array parameters (ie. info(String, Object[]), debug(String, Object[]) etc.) the wrong way. MessageFormatter.format(format, argArray) is used, but MessageFormatter.arrayFormat(format, argArray) should be used instead. Using the format() method results in putting the whole array in the first placeholder and leaving the following ones empty. Example: logger.info("1: {} 2: {} 3: {}", new Object[] { "ONE", "TWO", "THREE" }); Expected output: 1: ONE 2: TWO 3: THREE Actual output: 1: [ONE, TWO, THREE] 2: {} 3: {} -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 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 January 2011