[JBoss JIRA] Created: (JBAS-3838) ServerInfo does not check response from getThreadInfo for null
by Darran Lofthouse (JIRA)
ServerInfo does not check response from getThreadInfo for null
--------------------------------------------------------------
Key: JBAS-3838
URL: http://jira.jboss.com/jira/browse/JBAS-3838
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: MicroContainer bus
Affects Versions: JBossAS-4.0.5.GA
Reporter: Darran Lofthouse
Assigned To: Darran Lofthouse
Fix For: JBossAS-4.2.0.CR1
The ServerInfo MBean does not check the response from getThreadInfo for null. If getThreadInfo is called for a thread that no longer exists it returns null. Currently it is possible for the following NullPointerException to be logged: -
java.lang.NullPointerException
at sun.reflect.GeneratedMethodAccessor87.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.system.server.ServerInfo.getThreadCpuUtilization(ServerInfo.java:557)
at org.jboss.system.server.ServerInfo.listThreadCpuUtilization(ServerInfo.java:510)
at sun.reflect.GeneratedMethodAccessor113.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
--
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, 5 months
[JBoss JIRA] Created: (EJBTHREE-649) Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
by Andreas Zimmer (JIRA)
Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
---------------------------------------------------------------------------------------------------
Key: EJBTHREE-649
URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC8 - FD
Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
Reporter: Andreas Zimmer
Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
20 queries/reads within transaction - 10 msecs average per query/read
1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+)
With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.
--
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, 5 months
[JBoss JIRA] Created: (EJBTHREE-793) OneToMany (parent-child) with composite PK fails when inserting a child.
by Gunnar Grim (JIRA)
OneToMany (parent-child) with composite PK fails when inserting a child.
------------------------------------------------------------------------
Key: EJBTHREE-793
URL: http://jira.jboss.com/jira/browse/EJBTHREE-793
Project: EJB 3.0
Issue Type: Bug
Environment: Linux
Reporter: Gunnar Grim
OneToMany (parent-child) with composite PK on the child side fails when inserting a child. Only the first part of the PK has a value. Before em.persist, both key attributes have values but JBoss attempts to insert null into the second key attribute.
The application works fine on Sun Java Application Server 9.0 but fails on JBoss 4.0.5-GA.
The (stripped down) entity beans:
@Entity
@Table(name = "RelMain")
public class RelMain
implements Serializable
{
private Long itsMainID;
private String itsMainText;
private Set<RelSub> itsSubs;
public RelMain(Long pMainID)
{
itsMainID = pMainID;
}
@Id
@Column(name = "MainID", nullable = false)
public Long getMainID()
{
return itsMainID;
}
public void setMainID(Long pMainID)
{
itsMainID = pMainID;
}
@Column(name = "MainText")
public String getMainText()
{
return itsMainText;
}
public void setMainText(String pMainText)
{
itsMainText = pMainText;
}
@OneToMany(mappedBy="main", cascade={CascadeType.REMOVE})
public Set<RelSub> getSubs()
{
return itsSubs;
}
public void setSubs(Set<RelSub> pSubs)
{
itsSubs = pSubs;
}
}
@Entity
@Table(name = "RelSub")
public class RelSub
implements Serializable
{
private Long itsMainID;
private String itsSubNo;
private int itsSubValue;
private RelMain itsMain;
public RelSub(Long pMainID, String pSubNo)
{
itsMainID = pMainID;
itsSubNo = pSubNo;
}
@Id
@Column(name = "MainID", nullable = false)
public Long getMainID()
{
return itsMainID;
}
public void setMainID(Long pMainID)
{
itsMainID = pMainID;
}
@Id
@Column(name = "SubNo", nullable = false)
public String getSubNo()
{
return itsSubNo;
}
public void setSubNo(String pSubNo)
{
itsSubNo = pSubNo;
}
@Column(name = "SubValue")
public int getSubValue()
{
return itsSubValue;
}
public void setSubValue(int pSubValue)
{
itsSubValue = pSubValue;
}
@ManyToOne
@JoinColumns({
@JoinColumn(name="MainID", insertable=false, updatable=false)
})
public RelMain getMain()
{
return itsMain;
}
public void setMain(RelMain pMain)
{
itsMain = pMain;
}
}
--
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, 5 months
[JBoss JIRA] Created: (EJBTHREE-694) @OneToOne relation fails, when foreign key is in inverse side
by Martin Isheim (JIRA)
@OneToOne relation fails, when foreign key is in inverse side
-------------------------------------------------------------
Key: EJBTHREE-694
URL: http://jira.jboss.com/jira/browse/EJBTHREE-694
Project: EJB 3.0
Issue Type: Bug
Components: EJB3 Extensions
Affects Versions: EJB 3.0 RC8 - FD
Environment: JBoss AS 4.0.4 GA3 with jboss-EJB-3.0_RC8-FD installed as described in the release.
Reporter: Martin Isheim
I defined a OneToOne relation from "UserEntity" to "PasswordEntity", with the foreign key in the "PasswordEntity" (for historical reasons).
With EntityManager.persist() the entities were inserted into the database, but the foreignKey column in "PasswordEntity" is empty.
Reading the "UserEntity" provides an empty relation.
Here the getter from "UserEntity":
<code>
private PasswordEntity password;
@OneToOne(optional = true, cascade = CascadeType.ALL)
@PrimaryKeyJoinColumn(name = "ENTITYKEY", referencedColumnName = "USERKEY")
public PasswordEntity getPassword() {
return password;
}
</code>
Since the relation is unidirectional, "PaswordEntity" has no getter/setter.
Regards.
--
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, 5 months
[JBoss JIRA] Created: (EJBTHREE-684) Ejb3 deployer does not allow method overriding with Java 1.5 Covariant return types
by Swarn Dhaliwal (JIRA)
Ejb3 deployer does not allow method overriding with Java 1.5 Covariant return types
-----------------------------------------------------------------------------------
Key: EJBTHREE-684
URL: http://jira.jboss.com/jira/browse/EJBTHREE-684
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC8 - FD
Environment: Jboss-4.0.4.GA with ejb3 installed using the installer 'jboss-4.0.4.GA-Patch1-installer.jar'
Reporter: Swarn Dhaliwal
We have ejb3 entities which use method overiding with java 1.5 covariant return types. The code works correctly in jboss-4.0.4rc1 with ejb3 installed using the installer.
However when trying to deploy the same code in the aforementioned version a compilation exception is thrown indicating that there are duplicate methods in the class. The code looks like the following :
public abstract class AbstractEntity {
protected abstract Object getId();
}
public class ConcreteEntity extends AbstractEntity {
public String getId() {
return id;
}
}
--
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, 5 months
[JBoss JIRA] Created: (EJBTHREE-753) Incorect SQL with Compound Primary Keys
by SYARHEI MELESHKEVICH (JIRA)
Incorect SQL with Compound Primary Keys
---------------------------------------
Key: EJBTHREE-753
URL: http://jira.jboss.com/jira/browse/EJBTHREE-753
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC9 - FD
Environment: Tested on JBoss 4.0.4GA and jboss-EJB-3.0_Embeddable_ALPHA_9
Reporter: SYARHEI MELESHKEVICH
Priority: Blocker
Incorect SQL with duplicate columns generates when deployng example from Java EE 5 Tutorial http://java.sun.com/javaee/5/docs/tutorial/doc/PersistenceEJB2.html
@IdClass(order.entity.LineItemKey.class)
@Entity
@Table(name = "EJB_ORDER_LINEITEM")
public class LineItem {
@Id
public int getItemId() {
return itemId;
}
@Id
@Column(name="ORDERID", nullable=false, insertable=false, updatable=false)
public Integer getOrderId() {
return orderId;
}
}
public final class LineItemKey implements java.io.Serializable {
private Integer orderId;
private int itemId;
...
public Integer getOrderId() {
return orderId;
}
...
}
generates:
insert into EJB_ORDER_LINEITEM (ORDERID, quantity, VENDORPARTNUMBER, orderId, itemId) values (?, ?, ?, ?, ?)
ORDERID comes from LineItem class and orderId from LineItemKey.
--
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, 5 months
[JBoss JIRA] Created: (EJBTHREE-784) When updating an entity that has multiple Blob fields, the blob objects are getting swaped.
by Sandeep Ghosh (JIRA)
When updating an entity that has multiple Blob fields, the blob objects are getting swaped.
-------------------------------------------------------------------------------------------
Key: EJBTHREE-784
URL: http://jira.jboss.com/jira/browse/EJBTHREE-784
Project: EJB 3.0
Issue Type: Bug
Components: EJB3 Extensions
Environment: App server: JBoss 4.0.4GA
DB: Oracle 9i with the 10g driver.
Reporter: Sandeep Ghosh
We are trying to store two BLOB fields (using extended persistence) and after setting the two fields with the right binary data, the data is somehow switched between the fields. i.e. if image1 is to be set in colum1 and file2 in column2 after the db transaction is completed using an extended persistence context, image1 is set in column2 and file2 is set in column1.
Here's the entity class
@Entity
@Table(name = "GENE_CLONE_QC", uniqueConstraints = {})
public class GeneCloneQc implements java.io.Serializable {
@Lob @Basic(fetch=FetchType.EAGER)
@Column(name = "DELETED_SEQ", unique = false, nullable = true, insertable = true, updatable = true)
public String getDeletedSeq() {
return this.deletedSeq;
}
public void setDeletedSeq(String deletedSeq) {
this.deletedSeq = deletedSeq;
}
@Lob @Basic(fetch = FetchType.EAGER)
@Column(name = "QC_IMAGE", unique = false, nullable = true, insertable = true, updatable = true)
public Blob getQcImage() {
return this.qcImage;
}
public void setQcImage(Blob qcImage) {
this.qcImage = qcImage;
}
}
Here's the class with the save method that has the issue stated above
@Stateful
@Name("geneCloneQcBean")
@Scope(ScopeType.SESSION)
public class GeneCloneQcBean implements GeneCloneQcInf {
@PersistenceContext(type = PersistenceContextType.EXTENDED)
protected EntityManager entityManager;
public void save(){
if(qcImageFile != null){
Blob image = null;
try {
image = org.hibernate.Hibernate.createBlob(qcImageFile.getBytes());
} catch (IOException e) {
e.printStackTrace();
}
geneCloneQc.setQcImage(image);
}
if(sequenceDataFile != null){
Blob sequenceDataFileBlob = null;
try {
sequenceDataFileBlob = org.hibernate.Hibernate.createBlob(sequenceDataFile.getBytes());
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
String fileName = sequenceDataFile.getName();
fileName = fileName.substring(fileName.lastIndexOf("\\")+1);
geneCloneQc.setSequenceDataFileName(fileName);
geneCloneQc.setSequenceDataFile(sequenceDataFileBlob);
}
geneClone.setGeneCloneQc(geneCloneQc);
entityManager.persist(geneClone);
}
}
--
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, 5 months