[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.…
[View More]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
[View Less]
14 years
[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.…
[View More]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
[View Less]
14 years
[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 …
[View More]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
[View Less]
14 years
[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 …
[View More]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
[View Less]
14 years
[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.…
[View More]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
[View Less]
14 years