[JBoss JIRA] Created: (JBIDE-1841) Error #1 while performing SchemaExport if server isn't started.
by Anton Klimkovich (JIRA)
Error #1 while performing SchemaExport if server isn't started.
---------------------------------------------------------------
Key: JBIDE-1841
URL: http://jira.jboss.com/jira/browse/JBIDE-1841
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: Hibernate
Affects Versions: 2.0.1
Reporter: Anton Klimkovich
Priority: Minor
Attachments: exception.txt, TestHib.zip
EXECUTE: Import attached java project.
EXECUTE: Open Hibernate Configuration View
EXECUTE: Right mouse click and select Add Configuration from context menu
EXECUTE: On Main tab select imported project and path to cfg.xml
EXECUTE: On Clathpath tab set path to hsqldb.jar
EXECUTE: On Mappings tab add path to mapping file.
EXECUTE: Press Apply button and Ok button
ASSERT: Hibernate configuration appear in Hibernate Configuration View
EXECUTE: Right mouse click on configeration in Hibernate Configuration View and select Run SchemaExport
FAILURE: java.sql.SQLException: socket creation error
Log attached.
--
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
12 years, 1 month
[JBoss JIRA] Created: (JBIDE-2764) Split up build(s) in smaller pieces
by Max Rydahl Andersen (JIRA)
Split up build(s) in smaller pieces
-----------------------------------
Key: JBIDE-2764
URL: https://jira.jboss.org/jira/browse/JBIDE-2764
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: Build/Releng
Reporter: Max Rydahl Andersen
Fix For: LATER
Currently our build is very monolithic (for no real good reason) and that results in the build being very slow, not easy to see which component cause a failure since all dependents will also fail, respins takes alot of time ;(
We should split up the build in smaller parts (not necessarily all the way down to modules) which makes it possible to build the various part more or less independently by just being able to take the generated artifacts from dependent builds.
It would also be beneficial if the compile, test and upload parts gets separated so e.g. tests can be executed on separate platforms without having a full rebuild.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (JBIDE-7365) Trying to start a stopped EC2 instance results in infinite starting task
by Jeff Johnston (JIRA)
Trying to start a stopped EC2 instance results in infinite starting task
------------------------------------------------------------------------
Key: JBIDE-7365
URL: https://jira.jboss.org/browse/JBIDE-7365
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: deltacloud
Affects Versions: 3.2.0.Beta2
Reporter: Jeff Johnston
Using deltacloud 0.0.7, when an EC2 instance is stopped, it is no longer listed as TERMINATED as it was
in deltacloud 0.0.5. Instead, it is listed as STOPPED and the REST interface reports that a START action is
possible. This is not true. An EC2 instance, once stopped, is terminated and cannot be restarted. The Deltacloud
tools get the available actions from the REST interface and so if a user attempts to start the instance, the tools will
allow this and set up a task to wait for the state to change from STOPPED, but this will never happen and the task remains in the
task list indefinitely due to the fact that the task cannot be cancelled.
The Deltacloud tools currently does not support cancelling state-change-wait tasks because they are necessary to keep
the cached data up-to-date (e.g. we need to know when an instance in PENDING becomes RUNNING and if the user
has stopped an instance, we need to know when it is officially STOPPED or TERMINATED as this affects available actions,
for example. The task continuously waits and refreshes the instance, waiting for a state change. If a user requests another action,
the current wait-task will be cancelled and the new one will take it's place (e.g. one can STOP a PENDING instance that hasn't
achieved RUNNING state yet).
A bug has been opened against Deltacloud server: https://bugzilla.redhat.com/show_bug.cgi?id=64285 regarding the invalid
action/state settings for the stopped EC2 instance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month