FYI:
Apache Avalon has launched a new version of our website:
http://avalon.apache.org
The site focuses the new single Avalon platform and reflects much of the
recent changes in Avalon including the spinning off of the new Apache
Excalibur project. As such, much old documentation has been upd
The following comment has been added to this issue:
Author: Steve Brewin
Created: Tue, 6 Jul 2004 2:59 PM
Body:
Maybe stating the obvious, but in the code examples "localhost" is literal while
"hostname" is symbolic.
Replace "hostname" by a valid hostname within your local domai
Message:
A new issue has been created in JIRA.
-
View the issue:
http://issues.apache.org/jira/browse/JAMES-302
Here is an overview of the issue:
-
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]
> Sent: 06 July 2004 13:50
> To: James Developers List
> Subject: RE: User attribute support and API changes
>
>
>
>
>
> > I think this feels contrived, because I can't see the value
> in it, but
> > I could be wr
I could see implementation by delegation, and if we have a need for it, an
interface that specifies the an Attributes surface. So both of you are
correct, depending on the need we find. I don't see inheriting the
implementation, though.
Mind you, we want to be able to optimize this behavior. Fo
> I think this feels contrived, because I can't see the value in it, but I
> could be wrong.
I was confused by the name, "AttributeSupport" and initially thought
"AttributeManager" better described an object which managed a set of
attributes.
However I then wondered if you were perhaps trying
> -Original Message-
> From: Danny Angus [mailto:[EMAIL PROTECTED]
> Sent: 06 July 2004 09:53
> To: James Developers List
> Subject: Re: User attribute support and API changes
>
>
>
>
>
> What is your reasoning behind making attribute support a
> seperate interface to Mail or User
Intent and intent, this is a snip from the README:
"This SSL/TLS support in JavaMail works only when JavaMail is used on
a version of J2SE that includes SSL support. We have tested this
support on J2SE 1.4 and J2SE 1.5, which include SSL support. The
SSL support is provided by the JSSE package,
What is your reasoning behind making attribute support a seperate interface
to Mail or User?
Do you see any benefit to be gained from this polymorphism of Mail and
User, or is this just a "tidy mind" encapsulation of a single pattern of
attribute support?
FWIW I'm not 100% sure about this, let
> Hence this email - what are the thoughts concerning migration of James
> across to SVN?
Once we've acomplished the merge of head & support branch, +1.
***
The information in this e-mail is confidential and for use b
Some thoughts and notes on implementing the changes required for user
attributes.
I have added a new interface into the mailet API called AttributeSupport.
This interface defines the methods for accessing attributes that is common
to both User and Mail. Therefore User and Mail now implement
Attri
Gump Build Robot wrote:
-INFO- Failed with reason build failed
CLASSPATH :
/usr/local/gump/packages/phoenix-client.jar:
-
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(
I'm digging around in James HEAD looking at build procedures,
dependencies, gump, etc. etc. - trying to figure out how to set things
up so that they are nice and clean. I started to think "ok - we could
move this to there and that to here..." and then I remembered we are on
CVS not SVN.
Hence
13 matches
Mail list logo
