[jira] Updated: (GERONIMO-194) Date, time and datetime data type support for CMP entitiy beans
[ http://nagoya.apache.org/jira/browse/GERONIMO-194?page=history ] Gianny DAMOUR updated GERONIMO-194: --- Version: 1.0-M3 1.0-M2 Change affected versions. > Date, time and datetime data type support for CMP entitiy beans > --- > > Key: GERONIMO-194 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-194 > Project: Apache Geronimo > Type: Task > Components: OpenEJB > Versions: 1.0-M1, 1.0-M3, 1.0-M2 > Reporter: Dain Sundstrom > Assignee: Gianny DAMOUR > > OpenEJB 2.0M1 does not support temporal data types date, time and timestamp -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-194) Date, time and datetime data type support for CMP entitiy beans
[ http://nagoya.apache.org/jira/browse/GERONIMO-194?page=history ] Gianny DAMOUR reassigned GERONIMO-194: -- Assign To: Gianny DAMOUR > Date, time and datetime data type support for CMP entitiy beans > --- > > Key: GERONIMO-194 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-194 > Project: Apache Geronimo > Type: Task > Components: OpenEJB > Versions: 1.0-M1, 1.0-M3, 1.0-M2 > Reporter: Dain Sundstrom > Assignee: Gianny DAMOUR > > OpenEJB 2.0M1 does not support temporal data types date, time and timestamp -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-505) CMP - CMR and removed entity object detection
[ http://nagoya.apache.org/jira/browse/GERONIMO-505?page=history ] Gianny DAMOUR reassigned GERONIMO-505: -- Assign To: Gianny DAMOUR > CMP - CMR and removed entity object detection > - > > Key: GERONIMO-505 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-505 > Project: Apache Geronimo > Type: Bug > Components: OpenEJB > Versions: 1.0-M3 > Reporter: Gianny DAMOUR > Assignee: Gianny DAMOUR > > The container does not detect when a removed entity object is assigned to a > cmr-field of another object. > In such a case, the container should throw an IllegalArgumentException as per > the specifications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-505) CMP - CMR and removed entity object detection
CMP - CMR and removed entity object detection - Key: GERONIMO-505 URL: http://nagoya.apache.org/jira/browse/GERONIMO-505 Project: Apache Geronimo Type: Bug Components: OpenEJB Versions: 1.0-M3 Reporter: Gianny DAMOUR The container does not detect when a removed entity object is assigned to a cmr-field of another object. In such a case, the container should throw an IllegalArgumentException as per the specifications. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-504) dependencies defined by plan are not "validated"
[ http://nagoya.apache.org/jira/browse/GERONIMO-504?page=comments#action_55900 ] Jeremy Boynes commented on GERONIMO-504: I can see merit in validating during deployment as it would avoid the possibility of ClassNotFoundExceptions as we try to create GBean instances. However, this means that all dependencies would need to be present during deployment whereas in reality they may not actually be needed to deploy the module - for example, dependencies could be used to make classes available for application use (e.g. struts) but we would not need those to actually create the target configuration. Regardless of whether we check during deployment, the possibility of missing dependencies will always exist at configuration start time. For example, someone could have removed the dependency from the target server after the configuration had been installed. Given this, I would suggest we fix this by checking dependencies during normal deployment but that we also add an option to the deployer that would allow this check to be disabled. > dependencies defined by plan are not "validated" > > > Key: GERONIMO-504 > URL: http://nagoya.apache.org/jira/browse/GERONIMO-504 > Project: Apache Geronimo > Type: Wish > Components: deployment > Versions: 1.0-M3, 1.0-M2, 1.0-M1 > Reporter: Gianny DAMOUR > Priority: Minor > > elements defined by the various deployment plans are not > validated. It is possible to deploy successfully plans defining dependencies, > which are not defined by the installed repositories. > When such configurations are started, the Kernel throws as expected a > MissingDependencyException identifying the missing dependency. > This should be done upfront during deployment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-504) dependencies defined by plan are not "validated"
dependencies defined by plan are not "validated" Key: GERONIMO-504 URL: http://nagoya.apache.org/jira/browse/GERONIMO-504 Project: Apache Geronimo Type: Wish Components: deployment Versions: 1.0-M3, 1.0-M2, 1.0-M1 Reporter: Gianny DAMOUR Priority: Minor elements defined by the various deployment plans are not validated. It is possible to deploy successfully plans defining dependencies, which are not defined by the installed repositories. When such configurations are started, the Kernel throws as expected a MissingDependencyException identifying the missing dependency. This should be done upfront during deployment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
