[JBoss JIRA] Created: (EJBTHREE-843) @ManyToOne(cascade=CascadeType.REMOVE) produces delete of the reference of the relation, that is a nonsense
by Christophe Gildas (JIRA)
@ManyToOne(cascade=CascadeType.REMOVE) produces delete of the reference of the relation, that is a nonsense
-----------------------------------------------------------------------------------------------------------
Key: EJBTHREE-843
URL: http://jira.jboss.com/jira/browse/EJBTHREE-843
Project: EJB 3.0
Issue Type: Feature Request
Affects Versions: EJB 3.0 RC9 - Patch 1, EJB 3.0 RC9 - FD, EJB 3.0 RC8 - FD, EJB 3.0 RC10 - FD, EJB 3.0 RC11 - FD
Environment: Windows XP
Reporter: Christophe Gildas
If I define a relation @ManyToOne(cascade=CascadeType.REMOVE), when an instance of the POJO where is defined this relation is deleted, that produces a attempt to delete the target of the relation, which is the "parent" of the current POJO, that is a nonsense.
In this case, like that the "on delete cascade" of Oracle, the expected behaviour would rather be that deleting the target of the relation produces the destruction of all the instances of entities which have a foreign key of this target.
If I want to have this behaviour, I must define as much relations @OneToMany(cascade=CascadeType.REMOVE) in a POJO as this POJO has foireign keys
That can be very heavy, and a lot less flexible that to define this rule on each foreign key (as Oracle does).
--
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, 2 months
[JBoss JIRA] Created: (JBAS-4124) Using getDefaultSession istead of getSession in org/jboss/resource/adapter/mail/inflow/MailFolder.java
by Ilya (JIRA)
Using getDefaultSession istead of getSession in org/jboss/resource/adapter/mail/inflow/MailFolder.java
------------------------------------------------------------------------------------------------------
Key: JBAS-4124
URL: http://jira.jboss.com/jira/browse/JBAS-4124
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.0.5.GA
Environment: Linux
Reporter: Ilya
Assigned To: Weston Price
Priority: Critical
I'm using MDB of type org.jboss.resource.adapter.mail.inflow.MailListener
it was working incorrectly. Sometimes, out of blue, it stopped fetching mail with exception (which I could see after fix from JBAS-3769):
2007-02-02 11:51:52,220 ERROR [MailActivation] Failed to execute folder check, spec=MailActivationSpec(mailServer=10.0.0.1, storeProtocol=imap, mailFolder=INBOX, pollingInterval=60000, messageSelector=null, userName=***, maxMessages=1)
javax.mail.NoSuchProviderException: Invalid protocol: null
at javax.mail.Session.getProvider(Session.java:412)
at javax.mail.Session.getStore(Session.java:511)
at javax.mail.Session.getStore(Session.java:491)
at javax.mail.Session.getStore(Session.java:477)
at org.jboss.resource.adapter.mail.inflow.MailFolder.open(MailFolder.java:69)
at org.jboss.resource.adapter.mail.inflow.MailActivation.run(MailActivation.java:121)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
at java.lang.Thread.run(Thread.java:595)
problem was fixed, when I applyed this patch:
Index: src/main/org/jboss/resource/adapter/mail/inflow/MailFolder.java
===================================================================
--- src/main/org/jboss/resource/adapter/mail/inflow/MailFolder.java (revision 60713)
+++ src/main/org/jboss/resource/adapter/mail/inflow/MailFolder.java (working copy)
@@ -64,7 +64,8 @@
throws Exception
{
// Get a session object
- session = Session.getDefaultInstance(sessionProps);
+ session = Session.getInstance(sessionProps);
+
// Get a store object
store = session.getStore();
store.connect(mailServer, userName, password);
I believe that using getDefaultSession() was incorrect, because we don't need _defaul_ we need _our_ session =)
Please plan this to be fixed.
--
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, 2 months