Re: ERJavamail bug ?? - [SOLVED]
Re: ERJavamail bug ?? - [SOLVED]
- Subject: Re: ERJavamail bug ?? - [SOLVED]
- From: Amedeo Mantica <email@hidden>
- Date: Fri, 13 Jun 2008 20:42:58 +0200
Hi Simon
I corrected my subclassing from ERXAjaxApplication to EXRApplication,
but originally was ERXApplication, I changed it to ERXAjaxApplication
following a tutorial for Ajax applications in the wonder blog, may be
the tutorial was outdated, or I made some mistakes.
However now all works fine.
Thank you
Amedeo
:)
On 13/giu/08, at 12:43, Simon McLean wrote:
Hi Amed -
I've done some more digging on this. Like I said before, if you
subclass ERXApplication instead of ERXAjaxApplication (noting that
ERXApplication is itself a subclass of ERXAjaxApplication so you
don't loose any of the goodness!) then you wouldn't be having any
problems because I believe the problem is here:
During ERXApplication's constructor it posts an
ApplicationWillFinishLaunching notification which subsequently
causes frameworks to fire their "finishInitialization" method and it
is during this process that ERJavaMail calls
"initializeFrameworkFromSystemProperties".
ERXAjaxApplication does not post an ApplicationWillFinishLaunching,
which is I guess why your framework(s) are not being initialized.
So, maybe it's a bug in ERXAjaxApplication that this notification is
not posted? Or maybe it's not, because if you are building a wonder
app you should be subclassing ERXApplication.
I've only derived this from poking through the source. I am not
expert in the wonder app or framework initalisation process. So you
might want to find someone on the list who is a bit cleverer than me
to confirm this !!
Simon
On 13 Jun 2008, at 09:40, Amedeo Mantica wrote:
public class Application extends ERXAjaxApplication {
public static void main(String[] argv) {
ERXApplication.main(argv, Application.class);
}
public Application() {
NSLog.out.appendln("Welcome to " + name() + " !");
/* ** put your initialization code in here ** */
setContextClassName(ERXAjaxContext.class.getName());
ERXMessageEncoding.setDefaultEncodingForAllLanguages("UTF8");
ERJavaMail
.sharedInstance().initializeFrameworkFromSystemProperties();
}
}
Amed
On 12/giu/08, at 14:07, Simon McLean wrote:
so does you Application class subclass ERXAjaxApplication ?
if so then that's the problem. You need to subclass ERXApplication
(which itself is a subclass of ERXApplication for all the auto
initialise stuff to work. Or call it explicitly as you are now
doing.
Simon
On 12 Jun 2008, at 12:55, Amedeo Mantica wrote:
Hello Simon and all,
I looked at ERJavaMail sources, now I have put in my Application
constructor
ERJavaMail
.sharedInstance().initializeFrameworkFromSystemProperties();
but I don't understand why this method is not automatically called
Mine is an ERXAjaxApplication.
Thank you all
Regards
Amedeo
On 12/giu/08, at 12:54, Simon McLean wrote:
it is a wonder app (are you subclassing ERXApplication /
ERXSession etc) ?
if you are then you can create a properties file in your user
directory called WebObjects.properties (/users/simon/
WebObjects.properties for example) and put properties in there.
It's the last one to be read in when your app starts up so it
overrides anything in your apps and frameworks. we always
declare ERJavaMail settings there - particularly "centralise" as
that could be a disaster if it's set wrong !! It's also really
useful because different developers can have different
properties without upsetting your source control, and you can
have different properties on your production server so, for
example, you don't have to remember to switch centralise off
each time you install your app.
By the sounds of it, it's worth a clean up of all the various
properties files in your frameworks and apps too. Personally
when I create a new framework or app the first thing I do is
delete the entire contents of the properties file - particularly
all the default wonder stuff - because more often than not I've
already g them declared elsewhere and i don't want any confusion.
so i'd delete anything to do with ERJavaMail from all your
current properties files, create a WebObjects.properties file
and stick them all in there and see if that fixes it.
if it's not a wonder app then i'd definitely make it one :-)
Simon
On 12 Jun 2008, at 11:38, Amedeo Mantica wrote:
Hi Simon
1) Thank you very very much for the help
2) I have the ERJavaMail binary, my Properties are in the
Resources folder of my app, I don't know any other methods:
WebObjects.properties file ?? where????
or in the app properties --- OK i have set
er.javamail.centralize = false
or in the framework properties -- OK, er.javamail.centralize =
false
suggestion??
Thanks
Regards
Amedeo
On 11/giu/08, at 23:25, Simon McLean wrote:
Strange... The ERJavaMail shared instance can't see your
properties. Are you running off an ERJavaMail binary, or the
wonder source ? are your properties settings in your
WebObjects.properties file, or in the app properties, or in
the framework properties ?
Next step for me would be to download the wonder source and
stick it in your build path so that you can stick some break
points in there and figure out what's going wrong.
Simon
On 11 Jun 2008, at 20:25, Amedeo Mantica wrote:
sure:
ERMailDeliveryHTML mailToEsagono = new ERMailDeliveryHTML();
// Here ERMailDeliveryHTML needs a WOComponent to render
the HTML text content.
mailToEsagono.setComponent(toEsagono);
// Here you create a new instance of the message
// You can loop over this fragment of code, not forgetting
to use newMail ()
// before you set the attributes of the message.
Object[] tempArrayP = new Object[]
{System.getProperty("esagono.email")};
NSArray<String> tempP=new NSArray(tempArrayP);
try {
mailToEsagono.newMail();
mailToEsagono
.setFromAddress(System.getProperty("esagono.from.email"));
mailToEsagono
.setReplyToAddress(System.getProperty("esagono.from.email"));
mailToEsagono.setSubject("Esagono - Richiesta di
contatto");
mailToEsagono.setToAddresses(tempP);
// Send the mail. There is an optional sendMail(boolean)
that optionally blocks during the send.
mailToEsagono.sendMail();
emailSent = true;
} catch (Exception e) {
// handle the exception ...
e.printStackTrace();
System.out.println("Error sending mail to esagono");
emailSent = false;
}
On 11/giu/08, at 20:50, Simon McLean wrote:
Can you post the actual code ?
Simon
On 11 Jun 2008, at 19:00, Amedeo Mantica wrote:
Hi Simon, it's very strange!
The value is not null !, is exactly the value i put on the
properties file!
Regards
Amedeo
On 11/giu/08, at 16:58, Simon McLean wrote:
Are you sure that property is not getting overridden
somewhere else (like from the default wonder properties) ?
just before your exception do a:
log.debug("My admin email =
"+System.getProperty("er.javamail.adminEmail"));
and check it's value.
i bet it's null, in which case do a full text search for
"adminEmail" and see where else you are declaring it.
Simon
On 11 Jun 2008, at 15:24, David Avendasora wrote:
I ran into exactly this myself a couple months ago when
trying to set it up, but I figured it was just me doing
something wrong and moved on to other more pressing issues.
I was using:
er.javamail.adminEmail=email@hidden
So, I don't think it's anything with the parser not
liking the ".it", if anyone was thinking that.
Dave
On Jun 11, 2008, at 7:10 AM, Amedeo Mantica wrote:
java.lang.IllegalArgumentException: When setting
'er.javamail.centralize=true' (which means you just test
sending mails), you must also give a valid 'er.javamail.adminEmail=email@hidden
' to which the mails are sent.
at
er.javamail.ERMailDelivery.sendMail(ERMailDelivery.java:
338)
at
er.javamail.ERMailDelivery.sendMail(ERMailDelivery.java:
319)
at
net
.esagono
.components.ESContactForm.sendRequest(ESContactForm.java:
94)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
but...
.
.
# Mail
er.javamail.centralize=false
er.javamail.adminEmail=email@hidden
er.javamail.debugEnabled=true
er.javamail.milliSecondsWaitIfSenderOverflowed=6000
er.javamail.smtpHost=192.168.1.4
er.javamail.smtpAuth=false
er.javamail.smtpUser=
er.javamail.smtpPassword=
.
.
.
??? why?
_______________________________________________
Do not post admin requests to the list. They will be
ignored.
Webobjects-dev mailing list (email@hidden
)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be
ignored.
Webobjects-dev mailing list (email@hidden
)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden
)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden
)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden