Stefano,
I removed both jars and restarted. Once I sent a message to the
system the problem surfaced again:
java.lang.NoSuchMethodError:
org.apache.mailet.MailetContext.getSMTPHostAddresses(Ljava/lang/String;)Ljava/util/Iterator;
at
org.apache.james.transport.mailets.RemoteDelivery.deliver(RemoteDelivery.java:442)
at
org.apache.james.transport.mailets.RemoteDelivery.run(RemoteDelivery.java:1111)
at java.lang.Thread.run(Thread.java:595)
We've currently identified two patches that we will be applying:
http://sunsolve.sun.com/search/document.do?assetkey=1-21-118668-15-1
http://sunsolve.sun.com/search/document.do?assetkey=1-21-118669-15-1
I've included a list of all of the jars located in our james
installation and their locations here: http://pastie.caboo.se/148028
I noticed that there are the following jars in
james-2.3.0/bin/SAR-INF/lib/, mailet-2.3.jar, and mailet-api-2.3.jar.
I removed both 3.0 and 2.3 version of the jars, restarted and
attempted to send a message with the same outcome.
We will apply the sun patches and retest.
On Feb 5, 2008 8:37 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Remove mailet-api-3.0.jar and mailet-3.0.jar and restart.
>
> I don't know why you have mailet jars in your
> /zfs/james-2.3.0/bin/SAR-INF/lib/. That lib folder is for custom
> dependencies. The mailet jars are already contained in the sar file and
> automatically extracted by james at startup.
>
> Stefano
>
> [EMAIL PROTECTED] ha scritto:
>
> > Thank you Bernd & Stefano for your prompt replies. I have deployed
> > this james instance into a new zone that has never had james in it
> > before. I have run the find command from the / of the zone, and it is
> > as follows:
> >
> > inmail1[/]# find / -name mailet*.jar -ls
> > 1358 7 -rw-r--r-- 1 root root 6609 Feb 5 00:48
> > /zfs/james-2.3.0/work/ourProduct-james-1202194121076/SAR-INF/lib/mailet-api-3.0.jar
> > 1355 11 -rw-r--r-- 1 root root 10299 Feb 5 00:48
> > /zfs/james-2.3.0/work/ourProduct-james-1202194121076/SAR-INF/lib/mailet-2.3.jar
> > 1357 7 -rw-r--r-- 1 root root 6646 Feb 5 00:48
> > /zfs/james-2.3.0/work/ourProduct-james-1202194121076/SAR-INF/lib/mailet-api-2.3.jar
> > 1356 13 -rw-r--r-- 1 root root 12335 Feb 5 00:48
> > /zfs/james-2.3.0/work/ourProduct-james-1202194121076/SAR-INF/lib/mailet-3.0.jar
> > 390 8 -rw-r--r-- 1 501 501 6675 Jan 3 22:28
> > /zfs/james-2.3.0/bin/SAR-INF/lib/mailet-api-2.3.jar
> > 388 11 -rw-r--r-- 1 501 501 10475 Jan 3 22:28
> > /zfs/james-2.3.0/bin/SAR-INF/lib/mailet-2.3.jar
> > 391 7 -rw-r--r-- 1 501 501 6609 Jan 3 22:28
> > /zfs/james-2.3.0/bin/SAR-INF/lib/mailet-api-3.0.jar
> > 389 13 -rw-r--r-- 1 501 501 12335 Jan 3 22:28
> > /zfs/james-2.3.0/bin/SAR-INF/lib/mailet-3.0.jar
> >
> > We're using IPv4:
> > inmail1[/]# ifconfig -a
> > lo0:3: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
> > mtu 8232 index 1
> > inet 127.0.0.1 netmask ff000000
> > bge0:3: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
> > inet 192.168.18.222 netmask ffffff00 broadcast 192.168.18.255
> >
> > I will begin looking at the possibility that this could be caused by a
> > bug in the JVM shipped with Solaris 10. Is there anything else that I
> > could check from the James perspective?
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
