January 2011 - jboss-jira - Jboss List Archives

[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

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

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

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

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

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

13 years, 4 months

2
1
0 / 0

[JBoss JIRA] Issue Comment Edited: (JGRP-100) Large-scale JGroups

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-100?page=com.atlassian.jira.plugin.s... ] Bela Ban edited comment on JGRP-100 at 1/5/11 3:51 AM: ------------------------------------------------------- When we have many nodes in a cluster, the header overhead becomes bigger. E.g. a UUID address is 17 bytes (2 longs + 1 byte). If we have 100 nodes, a View for example is ca 1700 bytes ! A Digest might be even bigger, as it contains addresses and low/high seqnos ! If we have a small MTU (like in Infiniband (2048 bytes !), then we need to add FRAG just on top of the transport. The goal here is to make header and address overhead smaller. Headers by using IDs (shorts) for protocol names rather than strings. Addresses by using canonicalization ("ID" protocol), and replacing UUIDs with shorts. This is https://issues.jboss.org/browse/JGRP-931. However, as JGRP-931 didn't yield any perf improvements (albeit on small clusters), I closed JGRP-931. Might be re-opened later. was (Author: bela(a)jboss.com): When we have many nodes in a cluster, the header overhead becomes bigger. E.g. a UUID address is 17 bytes (2 longs + 1 byte). If we have 100 nodes, a View for example is ca 1700 bytes ! A Digest might be even bigger, as it contains addresses and low/high seqnos ! If we have a small MTU (like in Infiniband (2048 bytes !), then we need to add FRAG just on top of the transport. The goal here is to make header and address overhead smaller. Headers by using IDs (shorts) for protocol names rather than strings. Addresses by using canonicalization ("ID" protocol), and replacing UUIDs with shorts. > Large-scale JGroups > ------------------- > > Key: JGRP-100 > URL: https://issues.jboss.org/browse/JGRP-100 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.0 > > > - Run JGroups on hundreds of nodes (either physical, or simulation). > - Determine a protocol stack that can be used for large-scale execution > - Example: > - Coordinator may be SPOF. If coord is hung, messages will be sent, but no new views will > be generated > - Retransmission: retransmit from anyone (not sender, otherwise we have NAK implosion) > - Look at PBCAST -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMETA-326) Class-level @Asynchronous should only apply to the declared methods on the class

by Andrew Rubinger (JIRA)

Class-level @Asynchronous should only apply to the declared methods on the class -------------------------------------------------------------------------------- Key: JBMETA-326 URL: https://issues.jboss.org/browse/JBMETA-326 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Components: ejb Affects Versions: jboss-metadata-ejb-2.0.0-alpha-27 Reporter: Andrew Rubinger Assignee: Andrew Rubinger Fix For: jboss-metadata-ejb-2.0.0-alpha-28 Currently we're employing a "*" strategy applying to every business method of the bean. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (SECURITY-546) 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-546 URL: https://issues.jboss.org/browse/SECURITY-546 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

13 years, 4 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBRULES-2863) Tuple is null when firing an activation

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/JBRULES-2863?page=com.atlassian.jira.plug... ] Edson Tirelli updated JBRULES-2863: ----------------------------------- Component/s: drools-core > Tuple is null when firing an activation > --------------------------------------- > > Key: JBRULES-2863 > URL: https://issues.jboss.org/browse/JBRULES-2863 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-core > Affects Versions: 5.1.1.FINAL > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Priority: Critical > Fix For: 5.2.0.M1 > > > For some reason, an activation is firing with a nulled tuple, i.e., it seems the activation is being created, but not properly removed from the agenda. There are not many details but the rule in question uses both ruleflow-group and no-loop. > Reported by Dan Quinn. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2011