[jira] Closed: (JAMES-111) NPE at James.sendMail line 371

[ji...@apache.org]

Message:

   The following issue has been closed.

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/JAMES-111

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: JAMES-111
    Summary: NPE at James.sendMail line 371
       Type: Bug

     Status: Closed
 Resolution: FIXED

    Project: James
 Components: 
             James Core
   Versions:
             2.1

   Assignee: 
   Reporter: Peter Laurie

    Created: Mon, 23 Jun 2003 6:22 AM
    Updated: Sun, 6 Jun 2004 11:58 AM
Environment: Operating System: Linux
Platform: PC

Description:
Running 
  James 2.1.2
  Redhat 8.0
  JDK 1.4.1_01-b01
  Evolution 1.4.0

Symptom
An email from a pop3 account is not downloaded and all other email is blocked
for that account. Email from other accounts proceed correctly. The stacktrace
below appears in the scheduler-xxxx.log. Evolution continuously downloads a few
emails from James and presents them as new messages.

Resolution
When recognised, the offending emails were manually removed from the pop3
account using a webmail client. Functioned correctly after that.

I'm a bit confused - why does removing emails from the pop3 account affect the
sendMail function?

Analysis
message.getAllRecipients() returns a null.
sendMail() line 371 assumes that it will return an array.

This code is also currently in the top revision of this file in CVS.

Options
1) change Message.getAllRecipients to return an empty array instead of null.
2) change the James.sendMail() line 371 to handle the null case.

Note, that this maybe addressing the symptoms instead of the cause.

Stacktrace follows...
23/06/03 05:39:00 WARN  scheduler: Error occured executing trigger bigpond.com
java.lang.NullPointerException
        at org.apache.james.James.sendMail(James.java:371)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at
org.apache.avalon.phoenix.components.application.BlockInvocationHandler.invoke(BlockInvocationHandler.java:92)
        at $Proxy9.sendMail(Unknown Source)
        at org.apache.james.fetchpop.FetchPOP.targetTriggered(FetchPOP.java:86)
        at
org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler.doRunEntry(DefaultTimeScheduler.java:240)
        at
org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler.access$000(DefaultTimeScheduler.java:36)
        at
org.apache.avalon.cornerstone.blocks.scheduler.DefaultTimeScheduler$1.run(DefaultTimeScheduler.java:216)
        at
org.apache.avalon.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnable.java:47)
        at
org.apache.avalon.excalibur.thread.impl.WorkerThread.run(WorkerThread.java:80)


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.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


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org