You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by ma...@apache.org on 2004/01/29 07:29:00 UTC
cvs commit: jakarta-taglibs/mailer/src/org/apache/taglibs/mailer MailTag.java
martinc 2004/01/28 22:29:00
Modified: mailer/src/org/apache/taglibs/mailer MailTag.java
Log:
Use getInstance() rather than getDefaultInstance() to obtain the JavaMail
session, so that we have control over the instance (as opposed to picking
up a JVM-wide session).
PR: 24715
Submitted by: Daniel Abayev (dabayev at factset.com)
Revision Changes Path
1.12 +5 -5 jakarta-taglibs/mailer/src/org/apache/taglibs/mailer/MailTag.java
Index: MailTag.java
===================================================================
RCS file: /home/cvs/jakarta-taglibs/mailer/src/org/apache/taglibs/mailer/MailTag.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- MailTag.java 29 Jan 2004 06:18:11 -0000 1.11
+++ MailTag.java 29 Jan 2004 06:29:00 -0000 1.12
@@ -420,10 +420,10 @@
// create the session with an authenticator object
// better way to do authentication
props.put("mail.smtp.auth", "true");
- sessionobj = Session.getDefaultInstance(props,
+ sessionobj = Session.getInstance(props,
new MailAuthenticator(user, password));
} else
- sessionobj = Session.getDefaultInstance(props, null);
+ sessionobj = Session.getInstance(props, null);
message = new MimeMessage(sessionobj);
}
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-taglibs/mailer/src/org/apache/taglibs/mailer MailTag.java
Posted by Glenn Nielsen <gl...@mail.more.net>.
On Thu, Jan 29, 2004 at 12:41:29PM -0800, Martin Cooper wrote:
> On Thu, 29 Jan 2004, Glenn Nielsen wrote:
>
> > Martin,
> >
> > Thanks for taking over the Mailer taglib. There are many
> > ways it could be improved. Support for EL would be nice for
> > one thing.
>
> Yes, EL support is one of the things I was thinking about for a 2.0
> release, along with changing the usage model to be more natural, rather
> than being defined / constrained by how JavaMail wants to work.
>
> My thinking was to resolve all the outstanding issues and release a 1.2
> version, then start on the heavy lifting for 2.0. I'd welcome any other
> ideas you might have. (Obviously, I'll bring this subject up on a
> dedicated thread on the list nearer the time.)
Sounds like a plan. :-)
> >
> > There is a reason why Session.getDefaultInstance() was used.
> > This was for a virtual hosted environment to make sure that the
> > resource provider for the mail session could set headers, etc.
> > to make it easier to track what virtual host the email originated
> > from in case any complaints came in to postmaster or abuse.
>
> Urk. I was not aware of that. (I don't think it's documented anywhere.)
> Sorry. I'll back out the change and reopen the Bugzilla ticket until we
> can figure out another way to handle this. I'll also try to find a good
> place to document this... ;-)
Thanks,
Glenn
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: Project thoughts (WAS Re: cvs commit:
jakarta-taglibs/mailer/src/org/apache/taglibs/mailer MailTag.java)
Posted by Felipe Leme <ja...@felipeal.net>.
On Fri, 2004-01-30 at 02:46, Martin Cooper wrote:
> I hadn't even noticed that a bunch of attributes don't even allow RT
> expressions. That's easy to fix!
I thought it could be easy, but I was afraid these parameters were not
RT for some reason.
> As for EL support, this is presumably for JSP 1.2 users, since it comes
> for free with JSP 2.0.
JSP 2.0 makes the life of taglib developers much easier, but
unfortunately JSP 1.2 (and even 1.1) will be around for a long time yet
(can you believe I recently worked in a 7 digits project that relied on
JServ/JSP 1.0?).
> That gives us the choice of using either Commons EL
> or the JSTL 1.0 EL implementation. My preference would be for the former,
> since it's intended as an external API, and means we wouldn't require the
> Jakarta JSTL implementation to be present for the other taglibs to work.
I didn't think about that. As much as they're compatible, we could stick
with Commons. But if that's a problem, we could change Standard's
build.xml to generate some utility jars.
> One question: What happens when an EL-enabled tag is used in a JSP 2.0
> environment? Does the JSP 2.0 container evaluate the expressions, and if
> so, how do we handle those attributes? Or does the fact that the taglib
> declares itself as 1.2 mean that the container leaves the values alone. (I
> would assume the former, but I haven't checked the spec.)
That's a good question. I don't know if the container is smart enough to
handle EL evaluation to the proper channels depending on the TLD. But in
the worst case, we could have different TLDs/URI, like mailer (generic
TLD for 1.2 or 2.0) and mailer-EL (with EL support, only for JSP 1.2).
And that's another reason why we need to think/discuss a lot before
doing the changes (as we must have the same codebase that generate both
taglibs).
> Not sure how much can be made common, but in general, I like prefer common
> code to duplicated code. ;-)
I prefer that too.
> Could you clarify the last of these (super
> class)? Not sure what you're referring to here.
We could have a "SuperTagHandler" abstract class for each project and
that tag would provide common features (like methods to evaluate EL,
logging, etc..). Eventually, we could even have a base class in the
Common project (or whatever we call the new module) and then one in each
sub-project. The only drawback is the strong coupling between the class
(i.e, we would be implementing reuse by inheritance).
> > - make sure everything is standard among the tabligs (like using the XML
> > to generate TLDs and docs, make sure the TLDs follow the convention,
> > etc...)
>
> Yup.
I opened a bug recently because some TLDS are called taglibs-xxx while
other just xxx. Do you know which version is the correct?
> Yes, that's definitely a good idea. Do people have preferences on how we
> should do this? I've recently seen people espousing the benefits of Canoo
> WebTest, but I've never used it myself.
I never used such a framework neither. We could study/discuss the
possibilities:
- http://www.tagunit.org
- Canoo WebTest
- cactus
- something similar to JSTL's TCK
- ???
> Some of the taglibs may not need any further work, if their functionality
> has been subsumed by JSTL.
That's another issue: it's not clear if a taglib has become obsolete by
JSTL or not. I mean, there is a "deprecated taglibs" section, but only
xsl and Utility are in this situation. Maybe it's time for a "partially
deprecated" section which would list taglibs whose some functionalities
are now on JSTL - even though they provide more features. And even these
tags should be updated (offering EL support, for instance).
> have not yet done due diligence on this, but it would seem that (much of)
> the 'application', 'page', 'request' and 'session' taglibs is probably
Then these taglibs should be moved to the "deprecated" area.
> replaced by JSTL, and possibly 'dbtags', 'i18n' and 'xtags' as well.
Not sure about that, but I think these tags provide more features than
their peers at JSTL.
> Of what's left, I don't have a problem with signing up as the "official
> keeper" of a couple of other taglibs, as long as I'm familiar with the
> relevant functionality. (For example, I'm not going to sign up for the JMS
> taglib, since I don't know a whole lot about JMS.)
Agree. Each one should pick the tags he/she is more familiar with.
Anyway, that's one os the issues (having a committer responsible for
each taglibs). The other would be the general re-organization of the
tags (general EL support, common features, etc...).
If we continue discussing these issues in the list, we have made a
tremendous progress already :-)
Felipe
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: Project thoughts (WAS Re: cvs commit:
jakarta-taglibs/mailer/src/org/apache/taglibs/mailer MailTag.java)
Posted by Martin Cooper <ma...@apache.org>.
On Thu, 29 Jan 2004, Martin Cooper wrote:
> On Thu, 29 Jan 2004, Felipe Leme wrote:
>
> > On Thu, 2004-01-29 at 18:41, Martin Cooper wrote:
> > > On Thu, 29 Jan 2004, Glenn Nielsen wrote:
> > >
> > > > Martin,
> > > >
> > > > Thanks for taking over the Mailer taglib. There are many
> > > > ways it could be improved. Support for EL would be nice for
> > > > one thing.
> > >
> > > Yes, EL support is one of the things I was thinking about for a 2.0
> >
> > I think mailer needs EL and even RT support (for most of their
> > attributes). Right now, we should add at least RT support for CC, TO,
> > and other recipient fields.
> >
> > > My thinking was to resolve all the outstanding issues and release a 1.2
> > > version, then start on the heavy lifting for 2.0. I'd welcome any other
> > > ideas you might have. (Obviously, I'll bring this subject up on a
> > > dedicated thread on the list nearer the time.)
> >
> > I have some ideas for the project as a whole (not only mailer). I would
> > send these ideas to the list later, after I had some time to elaborate
> > them better, but now that you mentioned it, I better take advantage of
> > the timing. So, here they are:
>
> ;-)
>
> >
> > - both EL and RT support for all taglibs (provided we do it in an
> > organized way)
>
> I hadn't even noticed that a bunch of attributes don't even allow RT
> expressions. That's easy to fix!
>
> As for EL support, this is presumably for JSP 1.2 users, since it comes
> for free with JSP 2.0. That gives us the choice of using either Commons EL
> or the JSTL 1.0 EL implementation. My preference would be for the former,
> since it's intended as an external API, and means we wouldn't require the
> Jakarta JSTL implementation to be present for the other taglibs to work.
>
> One question: What happens when an EL-enabled tag is used in a JSP 2.0
> environment? Does the JSP 2.0 container evaluate the expressions, and if
> so, how do we handle those attributes? Or does the fact that the taglib
> declares itself as 1.2 mean that the container leaves the values alone. (I
> would assume the former, but I haven't checked the spec.)
Doh! s/former/latter/
--
Martin Cooper
>
> > - create a commons/core project with useful stuff to be used in all
> > taglibs (and even by other projects), such as:
> > - TEI/TLV validation
> > - easy way to add EL support
> > - super-class for all tags (although that's a technique many people
> > dislike), with proper support to logging, EL and other tasks
> > - etc...
>
> Not sure how much can be made common, but in general, I like prefer common
> code to duplicated code. ;-) Could you clarify the last of these (super
> class)? Not sure what you're referring to here.
>
> > - make sure everything is standard among the tabligs (like using the XML
> > to generate TLDs and docs, make sure the TLDs follow the convention,
> > etc...)
>
> Yup.
>
> > - provide test cases/unit testing
>
> Yes, that's definitely a good idea. Do people have preferences on how we
> should do this? I've recently seen people espousing the benefits of Canoo
> WebTest, but I've never used it myself.
>
> >
> >
> > Overall, I think the project as a whole seems a little bit "abandoned":
>
> I agree with you. There really hasn't been much going on here for a while
> now.
>
> >
> > - the latest releases of most taglibs (except Standard) is from
> > Feb/2003
> > - there are almost 100 opened bugs - except by Standard and now bugs
> > fixed by Martin, most of them don't get even description/comments by us
> > developers
> > - there is a lot of traffic in the users list, but most of them is
> > related to JSTL (or even Struts)
> > - etc...
> >
> > Right now, we have about 25 taglibs and 33 committers (although many of
> > them "retired" :). I know Pierre takes care of Standard and now Martin's
> > on Mailer, but I think it's time to get at least one "official keeper"
> > for each tag. If we can get say 8 committers with time for that, it
> > would be an average of 3 taglibs each
>
> Some of the taglibs may not need any further work, if their functionality
> has been subsumed by JSTL. Personally, I'm not interested in putting in
> the effort to maintain tags only useful in JSP 1.1 environments. ;-) I
> have not yet done due diligence on this, but it would seem that (much of)
> the 'application', 'page', 'request' and 'session' taglibs is probably
> replaced by JSTL, and possibly 'dbtags', 'i18n' and 'xtags' as well.
>
> Of what's left, I don't have a problem with signing up as the "official
> keeper" of a couple of other taglibs, as long as I'm familiar with the
> relevant functionality. (For example, I'm not going to sign up for the JMS
> taglib, since I don't know a whole lot about JMS.)
>
> --
> Martin Cooper
>
>
> >
> > So, what do you guys think?
> >
> > Felipe
> > (a 'freelancer' committer so far :-)
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: Project thoughts (WAS Re: cvs commit:
jakarta-taglibs/mailer/src/org/apache/taglibs/mailer MailTag.java)
Posted by Martin Cooper <ma...@apache.org>.
On Thu, 29 Jan 2004, Felipe Leme wrote:
> On Thu, 2004-01-29 at 18:41, Martin Cooper wrote:
> > On Thu, 29 Jan 2004, Glenn Nielsen wrote:
> >
> > > Martin,
> > >
> > > Thanks for taking over the Mailer taglib. There are many
> > > ways it could be improved. Support for EL would be nice for
> > > one thing.
> >
> > Yes, EL support is one of the things I was thinking about for a 2.0
>
> I think mailer needs EL and even RT support (for most of their
> attributes). Right now, we should add at least RT support for CC, TO,
> and other recipient fields.
>
> > My thinking was to resolve all the outstanding issues and release a 1.2
> > version, then start on the heavy lifting for 2.0. I'd welcome any other
> > ideas you might have. (Obviously, I'll bring this subject up on a
> > dedicated thread on the list nearer the time.)
>
> I have some ideas for the project as a whole (not only mailer). I would
> send these ideas to the list later, after I had some time to elaborate
> them better, but now that you mentioned it, I better take advantage of
> the timing. So, here they are:
;-)
>
> - both EL and RT support for all taglibs (provided we do it in an
> organized way)
I hadn't even noticed that a bunch of attributes don't even allow RT
expressions. That's easy to fix!
As for EL support, this is presumably for JSP 1.2 users, since it comes
for free with JSP 2.0. That gives us the choice of using either Commons EL
or the JSTL 1.0 EL implementation. My preference would be for the former,
since it's intended as an external API, and means we wouldn't require the
Jakarta JSTL implementation to be present for the other taglibs to work.
One question: What happens when an EL-enabled tag is used in a JSP 2.0
environment? Does the JSP 2.0 container evaluate the expressions, and if
so, how do we handle those attributes? Or does the fact that the taglib
declares itself as 1.2 mean that the container leaves the values alone. (I
would assume the former, but I haven't checked the spec.)
> - create a commons/core project with useful stuff to be used in all
> taglibs (and even by other projects), such as:
> - TEI/TLV validation
> - easy way to add EL support
> - super-class for all tags (although that's a technique many people
> dislike), with proper support to logging, EL and other tasks
> - etc...
Not sure how much can be made common, but in general, I like prefer common
code to duplicated code. ;-) Could you clarify the last of these (super
class)? Not sure what you're referring to here.
> - make sure everything is standard among the tabligs (like using the XML
> to generate TLDs and docs, make sure the TLDs follow the convention,
> etc...)
Yup.
> - provide test cases/unit testing
Yes, that's definitely a good idea. Do people have preferences on how we
should do this? I've recently seen people espousing the benefits of Canoo
WebTest, but I've never used it myself.
>
>
> Overall, I think the project as a whole seems a little bit "abandoned":
I agree with you. There really hasn't been much going on here for a while
now.
>
> - the latest releases of most taglibs (except Standard) is from
> Feb/2003
> - there are almost 100 opened bugs - except by Standard and now bugs
> fixed by Martin, most of them don't get even description/comments by us
> developers
> - there is a lot of traffic in the users list, but most of them is
> related to JSTL (or even Struts)
> - etc...
>
> Right now, we have about 25 taglibs and 33 committers (although many of
> them "retired" :). I know Pierre takes care of Standard and now Martin's
> on Mailer, but I think it's time to get at least one "official keeper"
> for each tag. If we can get say 8 committers with time for that, it
> would be an average of 3 taglibs each
Some of the taglibs may not need any further work, if their functionality
has been subsumed by JSTL. Personally, I'm not interested in putting in
the effort to maintain tags only useful in JSP 1.1 environments. ;-) I
have not yet done due diligence on this, but it would seem that (much of)
the 'application', 'page', 'request' and 'session' taglibs is probably
replaced by JSTL, and possibly 'dbtags', 'i18n' and 'xtags' as well.
Of what's left, I don't have a problem with signing up as the "official
keeper" of a couple of other taglibs, as long as I'm familiar with the
relevant functionality. (For example, I'm not going to sign up for the JMS
taglib, since I don't know a whole lot about JMS.)
--
Martin Cooper
>
> So, what do you guys think?
>
> Felipe
> (a 'freelancer' committer so far :-)
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Project thoughts (WAS Re: cvs commit:
jakarta-taglibs/mailer/src/org/apache/taglibs/mailer MailTag.java)
Posted by Felipe Leme <ja...@felipeal.net>.
On Thu, 2004-01-29 at 18:41, Martin Cooper wrote:
> On Thu, 29 Jan 2004, Glenn Nielsen wrote:
>
> > Martin,
> >
> > Thanks for taking over the Mailer taglib. There are many
> > ways it could be improved. Support for EL would be nice for
> > one thing.
>
> Yes, EL support is one of the things I was thinking about for a 2.0
I think mailer needs EL and even RT support (for most of their
attributes). Right now, we should add at least RT support for CC, TO,
and other recipient fields.
> My thinking was to resolve all the outstanding issues and release a 1.2
> version, then start on the heavy lifting for 2.0. I'd welcome any other
> ideas you might have. (Obviously, I'll bring this subject up on a
> dedicated thread on the list nearer the time.)
I have some ideas for the project as a whole (not only mailer). I would
send these ideas to the list later, after I had some time to elaborate
them better, but now that you mentioned it, I better take advantage of
the timing. So, here they are:
- both EL and RT support for all taglibs (provided we do it in an
organized way)
- create a commons/core project with useful stuff to be used in all
taglibs (and even by other projects), such as:
- TEI/TLV validation
- easy way to add EL support
- super-class for all tags (although that's a technique many people
dislike), with proper support to logging, EL and other tasks
- etc...
- make sure everything is standard among the tabligs (like using the XML
to generate TLDs and docs, make sure the TLDs follow the convention,
etc...)
- provide test cases/unit testing
Overall, I think the project as a whole seems a little bit "abandoned":
- the latest releases of most taglibs (except Standard) is from
Feb/2003
- there are almost 100 opened bugs - except by Standard and now bugs
fixed by Martin, most of them don't get even description/comments by us
developers
- there is a lot of traffic in the users list, but most of them is
related to JSTL (or even Struts)
- etc...
Right now, we have about 25 taglibs and 33 committers (although many of
them "retired" :). I know Pierre takes care of Standard and now Martin's
on Mailer, but I think it's time to get at least one "official keeper"
for each tag. If we can get say 8 committers with time for that, it
would be an average of 3 taglibs each
So, what do you guys think?
Felipe
(a 'freelancer' committer so far :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-taglibs/mailer/src/org/apache/taglibs/mailer
MailTag.java
Posted by Martin Cooper <ma...@apache.org>.
On Thu, 29 Jan 2004, Glenn Nielsen wrote:
> Martin,
>
> Thanks for taking over the Mailer taglib. There are many
> ways it could be improved. Support for EL would be nice for
> one thing.
Yes, EL support is one of the things I was thinking about for a 2.0
release, along with changing the usage model to be more natural, rather
than being defined / constrained by how JavaMail wants to work.
My thinking was to resolve all the outstanding issues and release a 1.2
version, then start on the heavy lifting for 2.0. I'd welcome any other
ideas you might have. (Obviously, I'll bring this subject up on a
dedicated thread on the list nearer the time.)
>
> There is a reason why Session.getDefaultInstance() was used.
> This was for a virtual hosted environment to make sure that the
> resource provider for the mail session could set headers, etc.
> to make it easier to track what virtual host the email originated
> from in case any complaints came in to postmaster or abuse.
Urk. I was not aware of that. (I don't think it's documented anywhere.)
Sorry. I'll back out the change and reopen the Bugzilla ticket until we
can figure out another way to handle this. I'll also try to find a good
place to document this... ;-)
--
Martin Cooper
>
> I am -1 for this patch as it is now. Perhaps there is a better
> solution that would allow either to be used, with the ability
> to prevent the Session.getInstance() by the application sever
> admin. That may be possible by using the java security policy.
>
> Regards,
>
> Glenn
>
> On Thu, Jan 29, 2004 at 06:29:00AM -0000, martinc@apache.org wrote:
> > martinc 2004/01/28 22:29:00
> >
> > Modified: mailer/src/org/apache/taglibs/mailer MailTag.java
> > Log:
> > Use getInstance() rather than getDefaultInstance() to obtain the JavaMail
> > session, so that we have control over the instance (as opposed to picking
> > up a JVM-wide session).
> >
> > PR: 24715
> > Submitted by: Daniel Abayev (dabayev at factset.com)
> >
> > Revision Changes Path
> > 1.12 +5 -5 jakarta-taglibs/mailer/src/org/apache/taglibs/mailer/MailTag.java
> >
> > Index: MailTag.java
> > ===================================================================
> > RCS file: /home/cvs/jakarta-taglibs/mailer/src/org/apache/taglibs/mailer/MailTag.java,v
> > retrieving revision 1.11
> > retrieving revision 1.12
> > diff -u -r1.11 -r1.12
> > --- MailTag.java 29 Jan 2004 06:18:11 -0000 1.11
> > +++ MailTag.java 29 Jan 2004 06:29:00 -0000 1.12
> > @@ -420,10 +420,10 @@
> > // create the session with an authenticator object
> > // better way to do authentication
> > props.put("mail.smtp.auth", "true");
> > - sessionobj = Session.getDefaultInstance(props,
> > + sessionobj = Session.getInstance(props,
> > new MailAuthenticator(user, password));
> > } else
> > - sessionobj = Session.getDefaultInstance(props, null);
> > + sessionobj = Session.getInstance(props, null);
> >
> > message = new MimeMessage(sessionobj);
> > }
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
> ----------------------------------------------------------------------
> Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-taglibs/mailer/src/org/apache/taglibs/mailer MailTag.java
Posted by Glenn Nielsen <gl...@mail.more.net>.
Martin,
Thanks for taking over the Mailer taglib. There are many
ways it could be improved. Support for EL would be nice for
one thing.
There is a reason why Session.getDefaultInstance() was used.
This was for a virtual hosted environment to make sure that the
resource provider for the mail session could set headers, etc.
to make it easier to track what virtual host the email originated
from in case any complaints came in to postmaster or abuse.
I am -1 for this patch as it is now. Perhaps there is a better
solution that would allow either to be used, with the ability
to prevent the Session.getInstance() by the application sever
admin. That may be possible by using the java security policy.
Regards,
Glenn
On Thu, Jan 29, 2004 at 06:29:00AM -0000, martinc@apache.org wrote:
> martinc 2004/01/28 22:29:00
>
> Modified: mailer/src/org/apache/taglibs/mailer MailTag.java
> Log:
> Use getInstance() rather than getDefaultInstance() to obtain the JavaMail
> session, so that we have control over the instance (as opposed to picking
> up a JVM-wide session).
>
> PR: 24715
> Submitted by: Daniel Abayev (dabayev at factset.com)
>
> Revision Changes Path
> 1.12 +5 -5 jakarta-taglibs/mailer/src/org/apache/taglibs/mailer/MailTag.java
>
> Index: MailTag.java
> ===================================================================
> RCS file: /home/cvs/jakarta-taglibs/mailer/src/org/apache/taglibs/mailer/MailTag.java,v
> retrieving revision 1.11
> retrieving revision 1.12
> diff -u -r1.11 -r1.12
> --- MailTag.java 29 Jan 2004 06:18:11 -0000 1.11
> +++ MailTag.java 29 Jan 2004 06:29:00 -0000 1.12
> @@ -420,10 +420,10 @@
> // create the session with an authenticator object
> // better way to do authentication
> props.put("mail.smtp.auth", "true");
> - sessionobj = Session.getDefaultInstance(props,
> + sessionobj = Session.getInstance(props,
> new MailAuthenticator(user, password));
> } else
> - sessionobj = Session.getDefaultInstance(props, null);
> + sessionobj = Session.getInstance(props, null);
>
> message = new MimeMessage(sessionobj);
> }
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org