[JBoss JIRA] Created: (JBCLUSTER-157) Server Shutdown Latency and Session replication and Forwarding
by Shankar Pattabiraman (JIRA)
Server Shutdown Latency and Session replication and Forwarding
--------------------------------------------------------------
Key: JBCLUSTER-157
URL: http://jira.jboss.com/jira/browse/JBCLUSTER-157
Project: JBoss Clustering
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Java 1.5.0_05, Win XP,Red Hat 3 JBoss 4.0.5 Apache
Reporter: Shankar Pattabiraman
Assigned To: Brian Stansberry
Priority: Minor
Setup a cluster with 2 nodes. Be in a session where a server is servicing.
Try to give a Control Z to kill the server while servicing. The latency involved in shutting down the server never gives a chance for the server to switch to the other.
The session in the latency period of shutdown never gets successfully switched to the other node in the cluster.
Apache-2 Node Jboss Cluster and a Trivial JEE Application.
Check this out whether it is a configuration issue or a real issue.
--
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
16 years, 6 months
[JBoss JIRA] Created: (EJBTHREE-686) Bidirectional @OneToOne with CascadeType.ALL and optional=false on the non-owning side:
by Jeremy Norris (JIRA)
Bidirectional @OneToOne with CascadeType.ALL and optional=false on the non-owning side:
---------------------------------------------------------------------------------------
Key: EJBTHREE-686
URL: http://jira.jboss.com/jira/browse/EJBTHREE-686
Project: EJB 3.0
Issue Type: Bug
Components: EJB3 Extensions
Affects Versions: EJB 3.0 RC8 - FD, EJB 3.0 RC7 - FD, EJB 3.0 RC6 - PFD
Reporter: Jeremy Norris
Consider the following two classes:
----- class X:
@Entity
@Table(name="x")
public class X
{
private Integer id;
private Y y;
public X()
{
this.y = new Y(this);
}
@Id
@GeneratedValue
@Column(name = "id", nullable=false, updatable=false)
public Integer getId()
{
return id;
}
protected void setId(Integer id)
{
this.id = id;
}
@OneToOne(cascade={CascadeType.ALL}, mappedBy="x")
public Y getY()
{
return y;
}
protected void setY(Y y)
{
this.y = y;
}
}
----- class Y:
@Entity
@Table(name="y")
public class Y
{
private Integer id;
private X x;
protected Y()
{
}
public Y(X x)
{
this.x = x;
x.setY(this);
}
@Id
@GeneratedValue
@Column(name = "id", nullable=false, updatable=false)
public Integer getId()
{
return id;
}
protected void setId(Integer id)
{
this.id = id;
}
@OneToOne
@JoinColumn(name="x_id", nullable=false)
public X getX()
{
return x;
}
protected void setX(X x)
{
this.x = x;
}
}
----- X is persisted as follows:
// Note: The constructor creates a new dependent Y instance, and hooks it up appropriately:
X x = new X();
em.persist(x);
-----
This works fine and persists as expected. However, if I add "optional=false" to the X.@OneToOne declaration, it fails with the following exception:
javax.ejb.EJBTransactionRolledbackException: javax.persistence.PersistenceException: org.hibernate.PropertyValueException: not-null property references a null or transient value: ... Y.x
Y.x definitely set. Also, "x == x.getY().getX()" is true. (Interestingly, this only happens if I put the "optional=false" on the X side. "optional=false" on the Y side is fine). This seems like a bug unless there is something I don't understand about "optional", but it seems pretty simply - The spec says the following about this attribute:
(Optional) Whether the association is optional.
If set to false then a non-null relationship must
always exist.
--
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
16 years, 6 months
[JBoss JIRA] Created: (GPD-67) GPD support for editing non-files (any IEditorInput, not just FileEditorInput)
by John Ruud (JIRA)
GPD support for editing non-files (any IEditorInput, not just FileEditorInput)
------------------------------------------------------------------------------
Key: GPD-67
URL: http://jira.jboss.com/jira/browse/GPD-67
Project: JBoss jBPM GPD
Issue Type: Feature Request
Reporter: John Ruud
Assigned To: Koen Aers
Priority: Minor
We need to edit process defs that are stored in a DB, as opposed to the processdefinition.xml, gpd.xml files stored in the workspace. There are currently many dependencies to FileEditorInput/File throughout GPD (as is the case for a lot of other Eclipse editors BTW).
It would be very helpful if it would be feasible to separate out the code that deals with a particular type of IEditorInput from the rest of the editor, possibly into a separete delegate class. For FileEditorInput the delegate would deal with reading, writing, and syncronizing the view (resource listeners), plus whatever else I may have forgotten. We could then replace the default "file" delegate with our own that knows how to deal our DB (by subclassing of the editor would be fine).
Probably not the #1 GPD issue for many other users, but hopefully something you would keep in mind...
--
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
16 years, 6 months