August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Resolved: (BPEL-187) wait activity

by Alejandro Guizar (JIRA)

[ http://jira.jboss.com/jira/browse/BPEL-187?page=all ] Alejandro Guizar resolved BPEL-187. ----------------------------------- Resolution: Done implemented time-driven activities on top of the jbpm scheduler service > wait activity > ------------- > > Key: BPEL-187 > URL: http://jira.jboss.com/jira/browse/BPEL-187 > Project: JBoss jBPM BPEL > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Engine > Affects Versions: jBPM BPEL 1.1 beta 1 > Reporter: Alejandro Guizar > Assigned To: Alejandro Guizar > Fix For: jBPM BPEL 1.1 beta 2 > > > allow for introducing delays in the process; ws-bpel 2.0 section 10.7. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (BPEL-208) scope within event handlers

by Alejandro Guizar (JIRA)

scope within event handlers --------------------------- Key: BPEL-208 URL: http://jira.jboss.com/jira/browse/BPEL-208 Project: JBoss jBPM BPEL Issue Type: Task Security Level: Public (Everyone can see) Components: Engine Affects Versions: jBPM BPEL 1.1 beta 1 Reporter: Alejandro Guizar Assigned To: Alejandro Guizar Fix For: jBPM BPEL 2.0 alpha In WS-BPEL 2.0, the target activity of message/alarm event handlers must be a scope to allow for local declarations. This change makes the token forked on each event occurrence redundant. When removing the redundancy, make sure the behavior is preserved for BPEL 1.1 processes where no restriction was placed on the target activity. Modifying the upgrade style sheet to wrap the activity in a <scope> (except when the activity is already a scope) seems enough. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBSEAM-329) Allow parameters to be passed into actions

by Stan Silvert (JIRA)

Allow parameters to be passed into actions ------------------------------------------ Key: JBSEAM-329 URL: http://jira.jboss.com/jira/browse/JBSEAM-329 Project: JBoss Seam Issue Type: Feature Request Affects Versions: 1.1 Reporter: Stan Silvert Assigned To: Stan Silvert Fix For: 1.1 USAGE The Action Params feature allows you to specify parameters when using the EL to call an action. So I can have something like this: <s:commandButton action="#{hotelBooking.bookHotel(hotel, user)}" class="button" value="Book Hotel" /> The parameters hotel and user will be evaluated as ValueExpressions and passed into the bookHotel method of your managed bean. This gives you an alternative to @In which forces injection to happen on every action method called. You can also pass in literal Strings using single or double quotes: <s:commandLink action="#{foo.bar( 'Here is my message' )}" value="Click Here" /> <s:commandLink action='#{foo.bar( "Here is my message" )}' value='Click Here' /> You might want to use this notation for all of your action methods, even when you don't have params to pass. This improves readability by making it clear that the expression is a MethodExpression and not a ValueExpression: <s:link value="Cancel" action="#{ hotelBooking.cancel() }" buttonClass="button" linkStyle="button"/> This is very handy for passing in JSF implicit objects: <page view-id="/mypage.jsp" action="#{foo.myMethod(facesContext, view)}" /> If you desire, you can still use the [ ] operator for your method as defined in the EL spec. If you do, you should put both the method and the params inside the [ ]: <s:commandLink action="#{ foo[ bar( facesContext ) ] }" value="Click Here" /> NEW TAGS As seen in the examples, Seam now has two new tags: <s:commandButton> <s:commandLink> These are drop-in replacements for <h:commandButton> and <h:commandLink>. For Facelets, the "class" attribute is added just as it is in the Facelets implementation of the corresponding tag. Note that these are JSF 1.1 style tags so they will not always work properly with <c:forEach>. Fixing this requires that the tags be written in the JSF 1.2 style. So, this can be fixed if and when we can assume JSF 1.2 is present. OLD TAGS <s:link> now supports action params. Actions defined in pages.xml now support action params as well. FACELETS SUPPORT To enable action params in Facelets, you will need to use the new SeamFaceletViewHandler instead of FaceletViewHandler. So, in faces-config.xml you will have: <application> <view-handler>org.jboss.seam.ui.facelet.SeamFaceletViewHandler</view-handler> </application> ISSUES Normally, when a MethodExpression or MethodBinding is created, the parameter types are passed in by hand. In the case of an action, JSF assumes that there are no params to pass. With action params in an expression, you can't know the param types until the parameters are evaluated. Evaluation of the params doesn't happen until the MethodExpression is invoked. This has two minor consequences: 1) If you call invoke on the MethodExpression by hand, any params you pass may be ignored. Params defined in the expression will take precedence. 2) Since Facelets uses MethodExpression instead of MethodBinding, you would normally be able to call myMethodExpression.getMethodInfo().getParamTypes() at any time. For an expression containing action params, you will only be able to do this after the method has been invoked at least once. Both of these cases are exceedingly rare and only apply when you want to invoke the MethodExpression by hand. Unlike other MethodExpressions and MethodBindings, with action params the method to invoke must be determined from the expression itself. It determines the right method based on these criteria: 1) The method name must match the method name in the expression 2) The number of parameters must match the number of params in the expression. It is possible, though unlikely, that more than one method will match the criteria. In that case, an exception is thrown explaining the criteria. I can probably fix this at some point, but it gets a little hairy. -- 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, 11 months

2
6
0 / 0

[JBoss JIRA] Created: (JBRULES-406) rename tag to category

by Michael Neale (JIRA)

rename tag to category ---------------------- Key: JBRULES-406 URL: http://jira.jboss.com/jira/browse/JBRULES-406 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale For ben -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-426) Memory leak in RuleHelperActionDelegate

by Kris Verlaenen (JIRA)

Memory leak in RuleHelperActionDelegate --------------------------------------- Key: JBRULES-426 URL: http://jira.jboss.com/jira/browse/JBRULES-426 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Eclipse IDE Reporter: Kris Verlaenen Assigned To: Kris Verlaenen Fix For: 3.0.4 The class RuleHelperActionDelegate ( svn) has a memory leak. Specifically: the Delegate itself is responsible for deleting any and all created Menu widgets. In the current implementation, the getMenu(Control) method is as follows: Menu menu = new Menu( parent ); final Shell shell = parent.getShell(); addProjectWizard( menu, shell ); addRuleWizard( menu,shell ); addDSLWizard( menu, shell ); addDTWizard( menu,shell ); return menu; Clearly, new menu widgets are created each time and are never disposed of. A correct implementation of this interface is available at org.eclipse.wst.server.ui.internal.webbrowser.SwitchBrowserWorkbenchAction . Specifically, the getMenu(Control) method should first dispose of the last menu, then create the new ones. public Menu getMenu(Control parent) { setMenu(new Menu(parent)); //fillMenu(fMenu); initMenu(); return fMenu; } private void setMenu(Menu menu) { if (fMenu != null) { fMenu.dispose(); } fMenu = menu; } So... ... ... he needs to destroy his menus before creating new ones =] -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-425) List of packages

by Michael Neale (JIRA)

List of packages ---------------- Key: JBRULES-425 URL: http://jira.jboss.com/jira/browse/JBRULES-425 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-408) List of categories

by Michael Neale (JIRA)

List of categories ------------------ Key: JBRULES-408 URL: http://jira.jboss.com/jira/browse/JBRULES-408 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale Need to be able to retrieve from the repository a list of categories: This can either be by passing the name of the parent category, and getting the child, OR by retrieving the whole tree (depending on size). I am leaning towards the whole tree, but perhaps doing it the first way is more generic, and we can cache the whole tree on the server side to start with. -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-414) Checkin initial project

by Michael Neale (JIRA)

Checkin initial project ----------------------- Key: JBRULES-414 URL: http://jira.jboss.com/jira/browse/JBRULES-414 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-407) List retrieval for categories

by Michael Neale (JIRA)

List retrieval for categories ----------------------------- Key: JBRULES-407 URL: http://jira.jboss.com/jira/browse/JBRULES-407 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale As categories are heirarchical, we need to be able to have some api like: List results = getRules(String[] categories) and all assets matching these categories are returned. eg: Cat1 / \ Cat2 Cat3 If a rule is linked to cat1, then if we are looking at Cat3, we will NOT see that rule. If another rule is put in Cat3, and we are looking at Cat1, we will see all the rules "below" it. (ie: when we pass in Cat1 to the query, it needs to know what categories are below it to include when searching for rules). at present, I believe this categorisation is probably one of the more important things to get right to make the repository useful (for large numbers of rules anyway - assuming all that versioning and ACL shite can be done). -- 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, 11 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-419) findByCategory retrieve a list of rules

by Michael Neale (JIRA)

findByCategory retrieve a list of rules --------------------------------------- Key: JBRULES-419 URL: http://jira.jboss.com/jira/browse/JBRULES-419 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Components: drools-brms Reporter: Michael Neale Assigned To: Michael Neale Need to be able to pass in a list of category tags, and return a list of rules that come under it. This is the heart of the classification scheme. List findByCategor(String[] categoryTags) return a flat list. -- 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, 11 months

1
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 August 2006