June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBAOP-80) AOP JoinPointFactory

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-80?page=all ] Kabir Khan closed JBAOP-80. --------------------------- Fix Version/s: 2.0.0.beta Resolution: Done This was done a while ago, I am closing it since no more requirements have come in > AOP JoinPointFactory > -------------------- > > Key: JBAOP-80 > URL: http://jira.jboss.com/jira/browse/JBAOP-80 > Project: JBoss AOP > Issue Type: Task > Reporter: Adrian Brock > Assigned To: Kabir Khan > Fix For: 2.0.0.beta > > > AOP should expose itself through the JoinPointFactory > in particular the invocations should implement the JoinPoint interfaces. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

1
0
0 / 0

[JBoss JIRA] Closed: (JBAOP-227) Test the proxy/advisor decision tree in the AOPJoinpointFactory

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-227?page=all ] Kabir Khan closed JBAOP-227. ---------------------------- Resolution: Done This was done a while ago, I am closing it since no more requirements have come in > Test the proxy/advisor decision tree in the AOPJoinpointFactory > --------------------------------------------------------------- > > Key: JBAOP-227 > URL: http://jira.jboss.com/jira/browse/JBAOP-227 > Project: JBoss AOP > Issue Type: Sub-task > Reporter: Adrian Brock > Assigned To: Kabir Khan > Fix For: 2.0.0.beta > > > The decision tree described on the attached forums thread needs fully testing. > http://www.jboss.com/index.html?module=bb&op=viewtopic&t=81869 > There are already some basic tests in aop-mc-int > see org.jboss.test.microcontainer.advisor.test.* -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBPM-955) jBPM: support setting Actor or Swimlane on process level (to re-use sub-processes)

by Arjan van Bentem (JIRA)

jBPM: support setting Actor or Swimlane on process level (to re-use sub-processes) ---------------------------------------------------------------------------------- Key: JBPM-955 URL: http://jira.jboss.com/jira/browse/JBPM-955 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM jPDL 3.2 Environment: All Reporter: Arjan van Bentem Assigned To: Tom Baeyens Priority: Minor Currently, an Actor or Swimlane is assigned within the task definition. When using sub-processes it would be very convenient to make the assignments in the parent process, such as in the parent <process-state>, or maybe even in the outermost <process-definition>. For example: both a helpdesk employee and the customer would need to fill in the same questionnaire at different points in the main process. The steps to fill in the questionnaire would be a generic sub-process, in which (at design time) one would not know the Swimlane nor Actor. This would require a way to set the swimlane in the parent's process-state:  <process-state name="Customer survey" swimlane="client"> <sub-process name="survey" /> </process-state> : : <process-state name="Employee survey" swimlane="employer"> <sub-process name="survey" /> </process-state> ... or <process-state name="Employee survey"> <assignment actor-id="..."/> <sub-process name="survey" /> </process-state> ... or maybe even at an even higher level, where jBPM would iterate up into the chain, possibly though nested sub-processes, until some assignment is found? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

2
7
0 / 0

[JBoss JIRA] Created: (JBRULES-955) Convenience method in DrlParser to expand DRL with a DSL

by Michael Neale (JIRA)

Convenience method in DrlParser to expand DRL with a DSL -------------------------------------------------------- Key: JBRULES-955 URL: http://jira.jboss.com/jira/browse/JBRULES-955 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.0.MR3 Reporter: Michael Neale Assigned To: Michael Neale Fix For: 4.0.0.MR4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

1
1
0 / 0

[JBoss JIRA] Closed: (JBRULES-313) Add halt/run commands

by Edson Tirelli (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-313?page=all ] Edson Tirelli closed JBRULES-313. --------------------------------- Resolution: Done Halt command is implemented. Just call from a rule consequence: drools.halt(); Or from your application: workingMemory.halt(); It will finish the execution of the current rule (in case it is executing one) and stop firing. To restart firing, just call fireAllRules() again. Test case here: http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-compiler/src/t... > Add halt/run commands > --------------------- > > Key: JBRULES-313 > URL: http://jira.jboss.com/jira/browse/JBRULES-313 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Environment: any > Reporter: Jacek Jarmulak > Assigned To: Edson Tirelli > Fix For: 4.0.0.MR4 > > > I have made a small modification to WorkingMemory and AbstractWorkingMemory that allows me to pause and the restart rule firing. > The change consists of adding a boolean isPaused flag (plus gettter and setter methods) which is then inspected in the while loop of the fireAllRules method as follows > public synchronized void fireAllRules(final AgendaFilter agendaFilter) throws FactException { > if ( !this.firing ) { > try { > this.firing = true; > while ( !this.isPaused() && this.agenda.fireNextItem( agendaFilter ) ) { > ; > } > } finally { > this.firing = false; > } > } > } > What is this good for? > It lets me stop rule firing from within some rule, e.g. when I want to execute an external call. > The rule sets up the call and then calls setPaused(true) on WorkingMemory. > Once fireAllRules exits, an external process executes the call, possibly asserting some facts into WorkingMemory > and then calls setPaused(false) and calls fireAllRules again. > Why not execute the call directly from the rule? > Because in my application the execution might take long time, and I want to have an option to move the WorkingMemory out of RAM, > possibly moving it to another app server to continue firing after the externall call processing has completed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-543) Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS

by Sridhar Chandrasekharan (JIRA)

Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS ---------------------------------------------------------------------------------------- Key: JBRULES-543 URL: http://jira.jboss.com/jira/browse/JBRULES-543 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Sridhar Chandrasekharan Assigned To: Mark Proctor Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS. Jess has a (halt) command which allows a rule to specify that rule execution should be stopped. I could find no such command in JBoss rules. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

2
3
0 / 0

[JBoss JIRA] Assigned: (JBRULES-313) Add halt/run commands

by Edson Tirelli (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-313?page=all ] Edson Tirelli reassigned JBRULES-313: ------------------------------------- Assignee: Edson Tirelli (was: Mark Proctor) > Add halt/run commands > --------------------- > > Key: JBRULES-313 > URL: http://jira.jboss.com/jira/browse/JBRULES-313 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Environment: any > Reporter: Jacek Jarmulak > Assigned To: Edson Tirelli > Fix For: 4.0.0.MR4 > > > I have made a small modification to WorkingMemory and AbstractWorkingMemory that allows me to pause and the restart rule firing. > The change consists of adding a boolean isPaused flag (plus gettter and setter methods) which is then inspected in the while loop of the fireAllRules method as follows > public synchronized void fireAllRules(final AgendaFilter agendaFilter) throws FactException { > if ( !this.firing ) { > try { > this.firing = true; > while ( !this.isPaused() && this.agenda.fireNextItem( agendaFilter ) ) { > ; > } > } finally { > this.firing = false; > } > } > } > What is this good for? > It lets me stop rule firing from within some rule, e.g. when I want to execute an external call. > The rule sets up the call and then calls setPaused(true) on WorkingMemory. > Once fireAllRules exits, an external process executes the call, possibly asserting some facts into WorkingMemory > and then calls setPaused(false) and calls fireAllRules again. > Why not execute the call directly from the rule? > Because in my application the execution might take long time, and I want to have an option to move the WorkingMemory out of RAM, > possibly moving it to another app server to continue firing after the externall call processing has completed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1487) CASAuthenticationValve has casServiceUrl, for which getter/setter are missing

by Advait (JIRA)

CASAuthenticationValve has casServiceUrl, for which getter/setter are missing ----------------------------------------------------------------------------- Key: JBPORTAL-1487 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1487 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Identity Environment: Windows 2000 Professional, JBoss AS 4.0.5 GA, JBoss Portal Server 2_6_CAS_Integration Reporter: Advait In 2_6_CAS_Integration branch of jboss portal, CASAuthenticationValve has casServiceUrl, for which getter/setter are missing. It allows us to route user to service url after authentication. Due to this, even if i put casServiceUrl in context.xml it was not taking effect. I have added them in local copy, and tested, and it is working, is this issue known? Thanks & Regards, Advait Trivedi -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JGRP-492) Benchmark against JBento ATL cluster

by Bela Ban (JIRA)

Benchmark against JBento ATL cluster ------------------------------------ Key: JGRP-492 URL: http://jira.jboss.com/jira/browse/JGRP-492 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Run the same session replication benchmarks as for 2.4.1 SP3 against 2.5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-4032) Restore jboss.partition.name property replacement in clustering beans.xml files

by Brian Stansberry (JIRA)

Restore jboss.partition.name property replacement in clustering beans.xml files ------------------------------------------------------------------------------- Key: JBAS-4032 URL: http://jira.jboss.com/jira/browse/JBAS-4032 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.Beta2 Pending completion of JBMICRONTAINER-143, I removed syntax from like the following from the clustering -beans.xml files: <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=HASingletonDeploymentScanner,partitionName=${jboss.partition.name:DefaultPartition}", exposedInterface=org.jboss.ha.singleton.HASingletonDeploymentScannerMBean.class, registerDirectly= true)</annotation> This task is a reminder to restore it once the microcontainer issue is resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 1 month

2
5
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 June 2007