September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPM-716) make the timer duedate optional

by Tom Baeyens (JIRA)

make the timer duedate optional ------------------------------- Key: JBPM-716 URL: http://jira.jboss.com/jira/browse/JBPM-716 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Reporter: Tom Baeyens Assigned To: Tom Baeyens Priority: Minor Fix For: jBPM 3.1.3, jBPM 3.2 alpha 1 now, it's not possible to have a timer without a dueDate. if we add a nullpointercheck, users can associate an action with the timer that fills in the dueDate programmatically. in org.jbpm.scheduler.def.CreateTimerAction a nullpointercheck should be added to the following two lines in the createTimer method : Duration duration = new Duration(dueDate); Date dueDate = businessCalendar.add( new Date(), duration ); -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Closed: (JBPM-325) task priority not set properly

by Tom Baeyens (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-325?page=all ] Tom Baeyens closed JBPM-325. ---------------------------- Resolution: Done > task priority not set properly > ------------------------------ > > Key: JBPM-325 > URL: http://jira.jboss.com/jira/browse/JBPM-325 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Fix For: jBPM 3.2 alpha 1 > > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBSEAM-355) Constructor injection of component dependencies

by Christian Bauer (JIRA)

Constructor injection of component dependencies ----------------------------------------------- Key: JBSEAM-355 URL: http://jira.jboss.com/jira/browse/JBSEAM-355 Project: JBoss Seam Issue Type: Feature Request Reporter: Christian Bauer Priority: Minor Take the registration example. The 'user' component is instantiated by Seam when JSF first looks for 'user' in a page. It is then put in the SESSION context (think CONVERSATION for other use cases of what I'm proposing). Seam uses the default constructor to instantiate the component. Now imagine that some attributes of User are immutable and that the only way to set their values is through a different constructor. Also imagine that these values are actually present when Seam instantiates the 'user' component, e.g. in the current CONVERSATION. I'd like to tell Seam to call my constructor and use EL to bind the arguments. Without this feature, immutable properties need to have public setter methods that I call later in an action method to wire in the required attributes manually. -- 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, 8 months

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-783) PojoCache to provide MBean interfaces

by Ben Wang (JIRA)

PojoCache to provide MBean interfaces ------------------------------------- Key: JBCACHE-783 URL: http://jira.jboss.com/jira/browse/JBCACHE-783 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0 In 2.0 release, since we are using delegation model for the core Cache, we can't no more rely on the underlying Cache to provide MBean interfaces. Instead, we are following the methodolody used in Cache. That is, we will have a .jmx.PojoCache class that has implemented the MBean interfaces and provide monitoring stats. We will share the flag useMbean in Configuration object to activate MBean service. -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (SECURITY-9) Mavenize Security Build

by Anil Saldhana (JIRA)

Mavenize Security Build ----------------------- Key: SECURITY-9 URL: http://jira.jboss.com/jira/browse/SECURITY-9 Project: JBoss Security Issue Type: Task Security Level: Public (Everyone can see) Components: JBossSX Affects Versions: 2.0 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0 Need to convert the security build into a maven based build. Reference: http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenBuildCreation https://svn.labs.jboss.org/labs/jbossbuild/trunk/projects/jboss/security/ (Prototype work by Ruel) -- 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, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-782) Rename Configuration.useInterceptorMbeans flag to reflect generic JMX behavior

by Ben Wang (JIRA)

Rename Configuration.useInterceptorMbeans flag to reflect generic JMX behavior ------------------------------------------------------------------------------ Key: JBCACHE-782 URL: http://jira.jboss.com/jira/browse/JBCACHE-782 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ben Wang Assigned To: Ben Wang Priority: Minor Fix For: 2.0.0 As agreed, we will rename this from useInterceptorMbeans to useMbean in Configuration. This flag will represent the generic JMX flag. -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-781) PojoCache creates a separate pojocache.jar for distro

by Ben Wang (JIRA)

PojoCache creates a separate pojocache.jar for distro ----------------------------------------------------- Key: JBCACHE-781 URL: http://jira.jboss.com/jira/browse/JBCACHE-781 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Priority: Critical Fix For: 2.0.0 In 2.0 release, we have created a separate jar file for PojoCache only: pojocache.jar, while keeping jboss-cache.jar to core Cache library. PojoCache users will need to put both pojocache.jar and jboss-cache.jar in their class path. -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-778) Refactor package distribution

by Ben Wang (JIRA)

Refactor package distribution ----------------------------- Key: JBCACHE-778 URL: http://jira.jboss.com/jira/browse/JBCACHE-778 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0 Per disucssion, we are refactoring the distribution package for release 2.0. 1. jboss-cache-core-dist.zip. Core edition that contains the tradition cache library. - Only Cache (jboss-cache.jar) and supporting library - Ref doc - faq - tutorial 2. jboss-cache-pojo-dist.zip. PojoCache edition. It has jboss-cache-core-dist.zip, plus - pojocache.jar that contains the PojoCache lib - additional JBoss Aop, trove, javassist, jboss-aop-jdk50.jar, qdox.jar - PojoCache ref doc - faq-pojo for PojoCache 3. jboss-cache-all-dist.zip. Everything PojoCache has, plus - javadoc - src -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Updated: (JBAS-1740) Remote Connection does not get closed in case of sloppy client

by Weston Price (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1740?page=all ] Weston Price updated JBAS-1740: ------------------------------- Fix Version/s: JBossAS-5.0.0.Beta (was: JBossAS-4.0.5.GA) Modfied according to JCA roadmap meeting. > Remote Connection does not get closed in case of sloppy client > -------------------------------------------------------------- > > Key: JBAS-1740 > URL: http://jira.jboss.com/jira/browse/JBAS-1740 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.1 Final > Reporter: Michael Kopp > Assigned To: Weston Price > Priority: Minor > Fix For: JBossAS-5.0.0.Beta > > > If the Client that gets a remote Connection (WrapperDataSourceService) does not close it properly (sloppy or crash), it will never be released again. > This can be solved rather easily, the finalize method of the Server part of the proxy should call close. > Thus if the client object gets garbage collected (or the JVM dies), the server object (proxy) will be garbage collected and the finalize method called. > This thing is that a sloppy or crashing client can occupy all available connections, leaving all other applications with no connection to work 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, 8 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-1740) Remote Connection does not get closed in case of sloppy client

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1740?page=comments#action_12343913 ] Dimitris Andreadis commented on JBAS-1740: ------------------------------------------ Weston, u working on this for 4.0.5? The parent tasks doesn't have a fix release assigned. > Remote Connection does not get closed in case of sloppy client > -------------------------------------------------------------- > > Key: JBAS-1740 > URL: http://jira.jboss.com/jira/browse/JBAS-1740 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JCA service > Affects Versions: JBossAS-4.0.1 Final > Reporter: Michael Kopp > Assigned To: Weston Price > Priority: Minor > Fix For: JBossAS-4.0.5.GA > > > If the Client that gets a remote Connection (WrapperDataSourceService) does not close it properly (sloppy or crash), it will never be released again. > This can be solved rather easily, the finalize method of the Server part of the proxy should call close. > Thus if the client object gets garbage collected (or the JVM dies), the server object (proxy) will be garbage collected and the finalize method called. > This thing is that a sloppy or crashing client can occupy all available connections, leaving all other applications with no connection to work 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, 8 months

1
0
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 September 2006