September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPM-751) unnecessary warning on valid process definition

by Alex Burgel (JIRA)

unnecessary warning on valid process definition ----------------------------------------------- Key: JBPM-751 URL: http://jira.jboss.com/jira/browse/JBPM-751 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1.2 Reporter: Alex Burgel Assigned To: Tom Baeyens Priority: Trivial i get this warning: process xml warning: warning: no swimlane or assignment specified for task '<task xmlns="urn:jbpm.org:jpdl-3.1" name="schedule" blocking="false" signalling="true" priority="normal"/>' it seems a bit odd to generate a warning on a valid process definition. i think it should either be illegal to have a task without an assignment or swimlane, or there shouldn't be any warning at all (maybe lower the logging level to INFO). -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBSEAM-354) Better support for JSF-style managed properties

by Adam Brod (JIRA)

Better support for JSF-style managed properties ----------------------------------------------- Key: JBSEAM-354 URL: http://jira.jboss.com/jira/browse/JBSEAM-354 Project: JBoss Seam Issue Type: Feature Request Components: JSF Affects Versions: 1.0.1 Reporter: Adam Brod Priority: Minor The @In annotation should support the same syntax as JSF managed properties. That means that If I have this annotation in my Bean: @In("#{param.fileId}") Long fileId Seam should automatically inject that property performing the correct JSF conversion. In Shale I can do that with the @Value or @Property annotation. It is very confusing that I need a specialized annotation that doesn't support the EL just for request parameters when JSF doesn't make that distinction. I believe this could be implemented with a few small changes to Component. Inside Component.getInstanceToInject(...), the logic which first checks to see if the name is an EL (line 1358 in Seam 1.0.1) could also check to see if the expression begins with "#{param.", if so, then it can call to Component.convertRequestParameter(...) to convert the type. This is a small change to Component, but it makes the overall Seam API more consistent. It allows me to use the EL anywhere I want. I don't have to worry about using @In or @RequestParameter, I just use the EL. -- 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, 10 months

2
1
0 / 0

[JBoss JIRA] Closed: (JBESB-68) Tidy-up JDBC classes

by Mohit Keswani (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-68?page=all ] Mohit Keswani closed JBESB-68. ------------------------------ Fix Version/s: 4.0 Beta 1 (was: 4.0) Resolution: Done Modified all helpers/persist classes to throw SQLException Modified method names to make them complete and logical. > Tidy-up JDBC classes > -------------------- > > Key: JBESB-68 > URL: http://jira.jboss.com/jira/browse/JBESB-68 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: ESB Core, Documentation > Affects Versions: 4.0 Alpha 1 > Reporter: Mark Little > Assigned To: Mohit Keswani > Priority: Minor > Fix For: 4.0 Beta 1 > > > - common\src\org\jboss\soa\esb\helpers\persist\JdbcCleanConn.java > 1) Refactor > - rename to conventions > - categorize exceptions instead of using Exception > - group into a db specific package instead of persist > - common\src\org\jboss\soa\esb\helpers\persist\SqlDbTable.java > 1) Refactor > - rename to conventions e.g getFldName - > getFieldName -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2193) abstract schema name with word limit in name

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2193?page=all ] Dimitris Andreadis updated JBAS-2193: ------------------------------------- Component/s: (was: EJB2) Assignee: Alexey Loubyansky Priority: Minor (was: Major) > abstract schema name with word limit in name > -------------------------------------------- > > Key: JBAS-2193 > URL: http://jira.jboss.com/jira/browse/JBAS-2193 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-4.0.3RC1 > Environment: OS: Windows XP and FreeBsd > Database: PostgreSQL 7.4 > Reporter: Yura Kravchuk > Assigned To: Alexey Loubyansky > Priority: Minor > Fix For: JBossAS-4.0.5.GA > > > We have few CMP entity beans with abstract schema name with word "limit", e.g. limitation_categories, limitation_durations, etc. We using dynamiq QL. It seems that query parser confused by word "limit" in schema name and thinks that it's clause LIMIT which placed before FROM clause. I changed schema name to lim_categories for entity bean and all works perfectly. > Herewith exception: > 17:02:28,671 INFO [STDOUT] javax.ejb.EJBException: SELECT COUNT($limit_category.id) FROM limit_category AS $limit_categ > ory; CausedByException is: > Can't count entities by expression and parameters; CausedByException is: > Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71. > Was expecting: > "FROM" ... > ; CausedByException is: > Can't count entities by expression and parameters; CausedByException is: > Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1536) Wrong SQL Type for Boolean Mapping for Derby Database

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1536?page=all ] Dimitris Andreadis updated JBAS-1536: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.GA) > Wrong SQL Type for Boolean Mapping for Derby Database > ----------------------------------------------------- > > Key: JBAS-1536 > URL: http://jira.jboss.com/jira/browse/JBAS-1536 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-4.0.1 Final > Environment: JBoss4.0.1; JDK1.5.0update1;Windows XP SP2;Derby 10.0.2.1 Embedded > Reporter: Ingo Bruell > Fix For: JBossAS-4.0.6.CR1 > > > The SQL datatype 'BOOLEAN' is not a valid datatype for the derby database. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-1535) PK Constraint name for Datbase Derby to long

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1535?page=all ] Dimitris Andreadis updated JBAS-1535: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.GA) > PK Constraint name for Datbase Derby to long > -------------------------------------------- > > Key: JBAS-1535 > URL: http://jira.jboss.com/jira/browse/JBAS-1535 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Affects Versions: JBossAS-4.0.1 Final > Environment: JBoss4.0.1; JDK1.5.0update1;Windows XP SP2;Derby 10.0.2.1 Embedded > Reporter: Ingo Bruell > Fix For: JBossAS-4.0.6.CR1 > > > In creating time of tables it could happen that a generated name for a pk constraint exceeds the limit of 18 characters. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-293) dynamic-ql sort order problem

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-293?page=all ] Dimitris Andreadis updated JBAS-293: ------------------------------------ Component/s: CMP service (was: EJB2) Fix Version/s: (was: JBossAS-4.0.5.GA) > dynamic-ql sort order problem > ----------------------------- > > Key: JBAS-293 > URL: http://jira.jboss.com/jira/browse/JBAS-293 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CMP service > Reporter: SourceForge User > > SourceForge Submitter: s2jcpete . > Conectiva 8.0 > JBoss-3.0.4 > j2sdk-1.4.0_02 > > When executing a dynamic-ql query in my CMP2.0 bean > everything gets returned correctly, but there is an issue with > the sorting. It will not return the data properly sorted no > matter what field I ask to sort, or the ASC/DESC. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAS-1714) -service.xml not deploying deploy/*.jar correctly

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-1714?page=all ] Dimitris Andreadis closed JBAS-1714. ------------------------------------ Fix Version/s: (was: JBossAS-4.0.5.GA) Resolution: Won't Fix the classpath element is rarely used. > -service.xml not deploying deploy/*.jar correctly > ------------------------------------------------- > > Key: JBAS-1714 > URL: http://jira.jboss.com/jira/browse/JBAS-1714 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Deployment services > Reporter: SourceForge User > > SourceForge Submitter: ioparra . > Refer to my previous postings in the forums: > http://www.jboss.org/thread.jsp? > forum=63&thread=36306 > The SAR Deployer is locking down jars in the deploy > directory instead of deploying those jars correctly. This > event occurs when you have a "classpath" entry in your > mbean. If that classpath has a codebase="."(ie, its > codebase is the deploy directory), this SAR Deployer > adds this jar to UCL repository. > Issues: > 1)the url for this jar points to the deploy directory(not a > temp directory) > a. when the service is run, this jar is no longer > deleteable(on windows, dunno about unix). > 2)The DirectoryScanner picks up this jar while scan. > The scanner copies/deploys the jar from the tmp > directory, leading to a new/managed UCL. The > UCLRepository doesn't know its a duplicate becuase it > compares the URLs(one url is from deploy, the other > from tmp). > Possible work-around/solution: > The SAR deployer already does a check if the > classpath="."(ie, the deploy directory). If true, call > mainDeployer.deploy(url) and don't call addURL. I > don't know the full implications of making this change. > If I have time, I'll try it out and post a patch. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3618) repository-zip target in build-release.xml doesn't consistently overwrite default config with all

by Alex Pinkin (JIRA)

repository-zip target in build-release.xml doesn't consistently overwrite default config with all ------------------------------------------------------------------------------------------------- Key: JBAS-3618 URL: http://jira.jboss.com/jira/browse/JBAS-3618 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Alex Pinkin <target name="repository-zip" description="Create a canonical binaries for the repository"> <mkdir dir="${version}/repository" /> <echo message="jboss.dist=${jboss.dist}" />  <copy todir="${jboss.dist}/server/lib"> <fileset dir="${jboss.dist}/server/minimal/lib" /> <fileset dir="${jboss.dist}/server/default/lib" /> <fileset dir="${jboss.dist}/server/all/lib" />  <fileset dir="${jboss.thirdparty}/quartz/lib" /> </copy>  <copy todir="${jboss.dist}/server/deploy"> <fileset dir="${jboss.dist}/server/default/deploy" /> <fileset dir="${jboss.dist}/server/all/deploy"> <exclude name="jms/**" /> </fileset>  <fileset dir="${jboss.cvs.dir}/connector/output/lib"> <include name="quartz-ra.rar" /> </fileset> </copy> <copy todir="${jboss.dist}/server/deploy-ha"> <fileset dir="${jboss.dist}/server/all"> <include name="deploy/jms/**" /> <include name="deploy-hasingleton/**" /> <include name="farm/**" /> </fileset> </copy> Ant's copy task only overwrites a file only if a file being copied has a newer timestamp. This causes inconsistent behavior depending on file timestamps. There is overwrite=true attribute which need to be added to force overwrites. -- 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, 10 months

2
2
0 / 0

[JBoss JIRA] Updated: (JBAS-2619) Add a testcase to validate that a registering deployer can take priority over accepting deployments for which a deployer already exists

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2619?page=all ] Dimitris Andreadis updated JBAS-2619: ------------------------------------- Fix Version/s: (was: JBossAS-4.0.5.GA) > Add a testcase to validate that a registering deployer can take priority over accepting deployments for which a deployer already exists > --------------------------------------------------------------------------------------------------------------------------------------- > > Key: JBAS-2619 > URL: http://jira.jboss.com/jira/browse/JBAS-2619 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Deployment services > Affects Versions: JBossAS-4.0.3 Final > Reporter: Dimitris Andreadis > > EJB3Deployer needs to make sure it can process deployments *before* the 2.1 EJBDeployer. -- 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, 10 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