You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Henri Yandell <ba...@generationjava.com> on 2003/08/08 04:35:00 UTC
Geronimo standard Sun-API jars
The first thing I'm looking for from Geronimo is not a working J2EE
server, but a redistributable version of:
javamail.jar
jms.jar
jdbc.jar [jdbc 3]
others? jdo?
j2ee.jar with all of the above.
Is this something Geronimo can do [even if the code is in Sun's naming
package]? If not, how do you ship a product with Sun licenced code.
How does JBoss manage to distribute javax.jms, java.jndi etc without
breaking the Sun licence?
Hen
RE: Geronimo standard Sun-API jars
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Incidentally it'd be *awesome* if Sun would donate a BSD licensed
> version of the official golden copy of the J2EE APIs. I'm sure
> we'd all volunteer to maintain them & submit future patches from Sun.
There are people at Sun who have been publicly promoting an Open Source J2EE
implementation for a long time, and who want to help support this effort.
Let's give Sun a little time to digest and decide how they want to
participate. The Apache J2EE project is new, and this is the height of
summer vacations.
--- Noel
Re: Geronimo standard Sun-API jars
Posted by James Strachan <ja...@yahoo.co.uk>.
On Friday, August 8, 2003, at 03:59 am, Henri Yandell wrote:
> On Thu, 7 Aug 2003, Jeremy Boynes wrote:
>
>> JBoss, like Tomcat, has its own version (typed in from the doc
>> apparently).
>> I believe Sun's binaries are actually redistributable if you meet
>> certain
>> terms (but you should have a lawyer read the license).
>>
>> The initial commit (later tonight I hope) contains copies of
>> javax.ejb and
>> javax.transaction Dain Sundstrom typed in.
>>
>> Given that these have use for many other projects, it might be a good
>> idea
>> to create a separate subproject, for example in jakarta-commons or
>> commons
>> itself, just to hold free versions of these interface classes rather
>> than
>> duplicating them everywhere.
>
> Wholeheartedly +1.
>
> As a secondary note, if we're able to distribute these under a BSD
> licence
> happily it'll be a superb first milestone for Geronimo and win Gerry a
> lot
> of friends and brand recognition.
Incidentally it'd be *awesome* if Sun would donate a BSD licensed
version of the official golden copy of the J2EE APIs. I'm sure we'd all
volunteer to maintain them & submit future patches from Sun.
James
-------
http://radio.weblogs.com/0112098/
RE: Geronimo standard Sun-API jars
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 7 Aug 2003, Jeremy Boynes wrote:
> JBoss, like Tomcat, has its own version (typed in from the doc apparently).
> I believe Sun's binaries are actually redistributable if you meet certain
> terms (but you should have a lawyer read the license).
>
> The initial commit (later tonight I hope) contains copies of javax.ejb and
> javax.transaction Dain Sundstrom typed in.
>
> Given that these have use for many other projects, it might be a good idea
> to create a separate subproject, for example in jakarta-commons or commons
> itself, just to hold free versions of these interface classes rather than
> duplicating them everywhere.
Wholeheartedly +1.
As a secondary note, if we're able to distribute these under a BSD licence
happily it'll be a superb first milestone for Geronimo and win Gerry a lot
of friends and brand recognition.
Hen
Re: Geronimo standard Sun-API jars
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On Thursday, August 7, 2003, at 10:55 PM, Jeremy Boynes wrote:
> JBoss, like Tomcat, has its own version (typed in from the doc
> apparently).
> I believe Sun's binaries are actually redistributable if you meet
> certain
> terms (but you should have a lawyer read the license).
>
> The initial commit (later tonight I hope) contains copies of javax.ejb
> and
> javax.transaction Dain Sundstrom typed in.
>
> Given that these have use for many other projects, it might be a good
> idea
> to create a separate subproject, for example in jakarta-commons or
> commons
> itself, just to hold free versions of these interface classes rather
> than
> duplicating them everywhere.
>
There's no reason why we couldn't just create them here, and ensure
that people can just grab them independently. One thing I'd like to
see this project do is offer the pieces separately as useful,
standalone components where that makes sense.
geir
> --
> Jeremy
>
>> -----Original Message-----
>> From: Henri Yandell [mailto:bayard@generationjava.com]
>> Sent: Thursday, August 07, 2003 7:35 PM
>> To: geronimo-dev@incubator.apache.org
>> Subject: Geronimo standard Sun-API jars
>>
>>
>>
>> The first thing I'm looking for from Geronimo is not a working J2EE
>> server, but a redistributable version of:
>>
>> javamail.jar
>> jms.jar
>> jdbc.jar [jdbc 3]
>> others? jdo?
>> j2ee.jar with all of the above.
>>
>> Is this something Geronimo can do [even if the code is in Sun's naming
>> package]? If not, how do you ship a product with Sun licenced code.
>>
>> How does JBoss manage to distribute javax.jms, java.jndi etc without
>> breaking the Sun licence?
>>
>> Hen
>>
>>
>
>
>
--
Geir Magnusson Jr 203-956-2604(w)
Adeptra, Inc. 203-434-2093(m)
geirm@adeptra.com 203-247-1713(m)
RE: Geronimo standard Sun-API jars
Posted by Jeremy Boynes <je...@coredevelopers.net>.
JBoss, like Tomcat, has its own version (typed in from the doc apparently).
I believe Sun's binaries are actually redistributable if you meet certain
terms (but you should have a lawyer read the license).
The initial commit (later tonight I hope) contains copies of javax.ejb and
javax.transaction Dain Sundstrom typed in.
Given that these have use for many other projects, it might be a good idea
to create a separate subproject, for example in jakarta-commons or commons
itself, just to hold free versions of these interface classes rather than
duplicating them everywhere.
--
Jeremy
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Thursday, August 07, 2003 7:35 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Geronimo standard Sun-API jars
>
>
>
> The first thing I'm looking for from Geronimo is not a working J2EE
> server, but a redistributable version of:
>
> javamail.jar
> jms.jar
> jdbc.jar [jdbc 3]
> others? jdo?
> j2ee.jar with all of the above.
>
> Is this something Geronimo can do [even if the code is in Sun's naming
> package]? If not, how do you ship a product with Sun licenced code.
>
> How does JBoss manage to distribute javax.jms, java.jndi etc without
> breaking the Sun licence?
>
> Hen
>
>
RE: Geronimo standard Sun-API jars
Posted by Danny Angus <da...@apache.org>.
Java mail is also complicated (slightly) in that sun's distributable also
comes with a refrence implementation archoved into the primary
redistributable jar.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 08 August 2003 04:12
> To: Henri Yandell; geronimo-dev@incubator.apache.org
> Subject: RE: Geronimo standard Sun-API jars
>
>
> Henri,
>
> > The first thing I'm looking for from Geronimo is not a working J2EE
> > server, but a redistributable version of [various Sun jar files].
>
> Check to see if each one is covered by the Sun BCL, but at least the
> JavaMail and JAF JAR files are distributable under the Sun BCL. See the
> Licensing page on the Wiki for more information.
>
> The basic issue is that you can only distribute them as part of a package.
> That is why if you download a James package, you get some, but if you look
> in the CVS, they aren't there. Part of the packaging process adds the
> necessary JAR files.
>
> --- Noel
>
RE: Geronimo standard Sun-API jars
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The maven guys have been trying to negociate with
> Sun to be able to distribute these jars.
> See http://maven.apache.org/sun-licensing-journey.html
And as part of this project, I'm sure that we'll be discussing some of these
packages with Sun. Let's remember that partnering with Sun is better than
viewing them as adversarial.
--- Noel
RE: Geronimo standard Sun-API jars
Posted by Tim Anderson <tm...@netspace.net.au>.
The maven guys have been trying to negociate with
Sun to be able to distribute these jars.
See http://maven.apache.org/sun-licensing-journey.html
-Tim
> -----Original Message-----
> From: Dain Sundstrom [mailto:dain@coredevelopers.net]
> Sent: Friday, 8 August 2003 1:35 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: Geronimo standard Sun-API jars
>
>
> Noel,
>
> I am willing to type everyone of these classes in by hand from the
> public documentation. It bugs me a a personal level that I can not
> download these jars in maven from ibiblio. For application developers,
> the situation it terrible, they either need to get install a full
> application server, an IDE with J2EE support, or download each one by
> hand from the Sun website just to build there applications.
>
> -dain
>
> On Thursday, August 7, 2003, at 10:11 PM, Noel J. Bergman wrote:
>
> > Henri,
> >
> >> The first thing I'm looking for from Geronimo is not a working J2EE
> >> server, but a redistributable version of [various Sun jar files].
> >
> > Check to see if each one is covered by the Sun BCL, but at least the
> > JavaMail and JAF JAR files are distributable under the Sun BCL. See
> > the
> > Licensing page on the Wiki for more information.
> >
> > The basic issue is that you can only distribute them as part of a
> > package.
> > That is why if you download a James package, you get some, but if you
> > look
> > in the CVS, they aren't there. Part of the packaging process adds the
> > necessary JAR files.
> >
> > --- Noel
>
>
Re: Geronimo standard Sun-API jars
Posted by Dain Sundstrom <da...@coredevelopers.net>.
Noel,
I am willing to type everyone of these classes in by hand from the
public documentation. It bugs me a a personal level that I can not
download these jars in maven from ibiblio. For application developers,
the situation it terrible, they either need to get install a full
application server, an IDE with J2EE support, or download each one by
hand from the Sun website just to build there applications.
-dain
On Thursday, August 7, 2003, at 10:11 PM, Noel J. Bergman wrote:
> Henri,
>
>> The first thing I'm looking for from Geronimo is not a working J2EE
>> server, but a redistributable version of [various Sun jar files].
>
> Check to see if each one is covered by the Sun BCL, but at least the
> JavaMail and JAF JAR files are distributable under the Sun BCL. See
> the
> Licensing page on the Wiki for more information.
>
> The basic issue is that you can only distribute them as part of a
> package.
> That is why if you download a James package, you get some, but if you
> look
> in the CVS, they aren't there. Part of the packaging process adds the
> necessary JAR files.
>
> --- Noel
RE: Geronimo standard Sun-API jars
Posted by "Noel J. Bergman" <no...@devtech.com>.
Henri,
> The first thing I'm looking for from Geronimo is not a working J2EE
> server, but a redistributable version of [various Sun jar files].
Check to see if each one is covered by the Sun BCL, but at least the
JavaMail and JAF JAR files are distributable under the Sun BCL. See the
Licensing page on the Wiki for more information.
The basic issue is that you can only distribute them as part of a package.
That is why if you download a James package, you get some, but if you look
in the CVS, they aren't there. Part of the packaging process adds the
necessary JAR files.
--- Noel
RE: Geronimo standard Sun-API jars (JavaMail)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Anyone know why the Maillet API didn't subclass Servlet, BTW?
<<sigh>> Someone brings this up at least every 6 months.
> public class Maillet extends GenericServlet {
> public void service(SMTPRequest request, SMTPResponse)
> throws ServletException, IOEXcception {
The mailet pipeline isn't request/response, nor is it coupled with SMTP.
Don't confuse the asynchronous mailet pipeline with the synchronous protocol
handler. :-)
But please, if you want to discuss this, server-dev@james.apache.org is a
better place.
--- Noel
RE: Geronimo standard Sun-API jars (JavaMail)
Posted by Danny Angus <da...@apache.org>.
Richard Monson-Haefel wrote,
> I think it would be a good idea to support Jame's current
> component model as
> well as providing an adapter that bridges the gap between Mailets and the
> Message Driven Bean model. Both are useful. For Geronimo the MDB adapter
> would be useful because it would allow James to plug directly into the
> message driven bean container system. There are some problems like
> transactional messaging (perhaps James addresses this I'm not
> sure yet), but
> overall providing Mailet support through the J2EE standard MDB component
> model, as well as the "native" James component is a good thing..
javaMail provides an interface for implementations of protocols.
James currently implements Mailet by passing every SMTP message, out going
or incoming, into a single message pipeline, this pipeline is the mailet
container and mailets are used to implement server functionality.
You know remote/local delivery, spam filtering, list serving etc.
This is partly achieved by allowing mailets to kill messages and insert new
ones at the top of the pipe, and partly by making the whole thing an
asynchronous spool, mail is put in at one rate and processed at another.
It should be equally possible to implement a J2EE compliant "mail service
provider" in the form of a "Transport" for SMTP which was itself a self
contained mailet pipeline, we'd have to look closely into the provider
lifecycles to see how feasable this is though.
In that way while javaMail is not well suited to building servers it would
still be possible to add Mailet to to our javaMail impl. for outgoing mail
in a compliant manner. :-)
d.
Re: Geronimo standard Sun-API jars (JavaMail)
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
James Strachan wrote:
> >
> > public class Maillet extends GenericServlet {
> > public void service(SMTPRequest request, SMTPResponse) throws
> > ServletException, IOEXcception {
> > }
> > }
> > would have been a really good way to handle incoming SMTP messages
> > (viewing the Request/Response pair as a 'channel' rather than a
> > one-off HTTP input/output).
>
> I always wondered why more protocols didn't extend the Servlet spec.
> e.g. I wrote a JMS extended Servlet API (the 'messagelet API' ) as part
> of the Messenger project in Jakarta Commons and it worked out quite
> nicely. Processing email or SOAP requests would work out quite
> similarly too I suppose.
>
> Having said that - I think there's a common OO gotcha where we think we
> should reuse things because they're there & reuse is good. Its often
> better to use an API that accurately reflects what your actual
> application requires - rather than reusing an API just because its
> there. Otherwise you might find you end up with a leaky abstraction.
I think it would be a good idea to support Jame's current component model as
well as providing an adapter that bridges the gap between Mailets and the
Message Driven Bean model. Both are useful. For Geronimo the MDB adapter
would be useful because it would allow James to plug directly into the
message driven bean container system. There are some problems like
transactional messaging (perhaps James addresses this I'm not sure yet), but
overall providing Mailet support through the J2EE standard MDB component
model, as well as the "native" James component is a good thing..
As far as modifying James: That was never my intention. My thoughts are to
write an adapter, perhaps a J2EE Connector, that bridges the gap between the
James Mailet and MDB component model. Obviously, a lot more research has to
be done on the topic before we know if this would work.
Richard
--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com
RE: Geronimo standard Sun-API jars (JavaMail)
Posted by Danny Angus <da...@apache.org>.
James wrote:
> I guess the James folks considered reusing the Servlet API right?
Right, although I wasn't involved then I know that it was part of the
original idea.
It has been recondered and rejected several times since as well, for reasons
I'm beginning to agree with. :-)
Re: Geronimo standard Sun-API jars (JavaMail)
Posted by James Strachan <ja...@yahoo.co.uk>.
On Friday, August 8, 2003, at 01:45 pm, Alex Blewitt wrote:
>
> On Friday, Aug 8, 2003, at 11:36 Europe/London, Danny Angus wrote:
>
>> Henri wrote:
>>
>>> The first thing I'm looking for from Geronimo is not a working J2EE
>>> server, but a redistributable version of:
>>>
>>> javamail.jar
>>
>> None of this is beyond the scope of a re-implementation, but it isn't
>> trivial and questions would have to be answered about the value of
>> this
>> effort given that JavaMail is, by Sun's own admission a client-side
>> API not
>> a server one, and that the James project have already uncovered a
>> number of
>> gotchas for server development caused by this client focus.
>
> One major gotcha, for example, is that the JavaMail API doesn't
> provide a JavaBean view of a message. That is, you can do
> ${message.subject} but not ${message.content} since the getContent and
> setContent methods take different argument types (which buggers up
> Introspection).
> Object getContent()
> void setContent(Part part)
>
> It also has some decidedly odd interfaces, such as void setFrom() as
> well as void setFrom(Address address)
>
>> The best thing we could do as a community in relation to mail, in my
>> very
>> humble opinion, would be to extend the API in geronimo to provide the
>> framework for server functionality which we miss, and to include an
>> implementation of the Apache Mailet API, but this would depend
>> heavily upon
>> the direction the project takes with respect to whether geronimo is
>> (or
>> tries to be) the J2EE RI or just a top quality product.
>>
>> I believe that the Mailet API is, for mail, much more closely aligned
>> with
>> the principles of J2EE than javaMail is, which probably really
>> belongs in
>> J2SE.
>
> I concur. JavaMail is fairly fundamentally broken (as described above)
> and what's needed is a better implementation. However, it doesn't
> preclude a set of JavaMail-esque wrappers to facilitate interfaces by
> those that are expecting it, but the preference would be to provide a
> cleaner implementation.
>
> Maillet support would be great, and one thing I don't think any other
> J2EE server supports is a Mail-request based protocol, to allow (for
> example) JMS to be sent over the top of SMTP, or trigger incoming
> mails.
>
> Anyone know why the Maillet API didn't subclass Servlet, BTW? I'd have
> thought that
>
> public class Maillet extends GenericServlet {
> public void service(SMTPRequest request, SMTPResponse) throws
> ServletException, IOEXcception {
> }
> }
> would have been a really good way to handle incoming SMTP messages
> (viewing the Request/Response pair as a 'channel' rather than a
> one-off HTTP input/output).
I always wondered why more protocols didn't extend the Servlet spec.
e.g. I wrote a JMS extended Servlet API (the 'messagelet API' ) as part
of the Messenger project in Jakarta Commons and it worked out quite
nicely. Processing email or SOAP requests would work out quite
similarly too I suppose.
Having said that - I think there's a common OO gotcha where we think we
should reuse things because they're there & reuse is good. Its often
better to use an API that accurately reflects what your actual
application requires - rather than reusing an API just because its
there. Otherwise you might find you end up with a leaky abstraction.
I guess the James folks considered reusing the Servlet API right?
James
-------
http://radio.weblogs.com/0112098/
RE: Geronimo standard Sun-API jars (JavaMail)
Posted by Danny Angus <da...@apache.org>.
> Anyone know why the Maillet API didn't subclass Servlet, BTW? I'd have
> thought that
>
> public class Maillet extends GenericServlet {
> public void service(SMTPRequest request, SMTPResponse) throws
> ServletException, IOEXcception {
> }
> }
>
> would have been a really good way to handle incoming SMTP messages
> (viewing the Request/Response pair as a 'channel' rather than a one-off
> HTTP input/output).
Mailet provides for asynchronous processing of mail messages not
request-response handling.
That aside Servlet now contains some parts which an asynchronous mail API
would not be easily able to implement.
d.
Re: Geronimo standard Sun-API jars (JavaMail)
Posted by Alex Blewitt <Al...@ioshq.com>.
On Friday, Aug 8, 2003, at 11:36 Europe/London, Danny Angus wrote:
> Henri wrote:
>
>> The first thing I'm looking for from Geronimo is not a working J2EE
>> server, but a redistributable version of:
>>
>> javamail.jar
>
> None of this is beyond the scope of a re-implementation, but it isn't
> trivial and questions would have to be answered about the value of this
> effort given that JavaMail is, by Sun's own admission a client-side
> API not
> a server one, and that the James project have already uncovered a
> number of
> gotchas for server development caused by this client focus.
One major gotcha, for example, is that the JavaMail API doesn't provide
a JavaBean view of a message. That is, you can do ${message.subject}
but not ${message.content} since the getContent and setContent methods
take different argument types (which buggers up Introspection).
Object getContent()
void setContent(Part part)
It also has some decidedly odd interfaces, such as void setFrom() as
well as void setFrom(Address address)
> The best thing we could do as a community in relation to mail, in my
> very
> humble opinion, would be to extend the API in geronimo to provide the
> framework for server functionality which we miss, and to include an
> implementation of the Apache Mailet API, but this would depend heavily
> upon
> the direction the project takes with respect to whether geronimo is (or
> tries to be) the J2EE RI or just a top quality product.
>
> I believe that the Mailet API is, for mail, much more closely aligned
> with
> the principles of J2EE than javaMail is, which probably really belongs
> in
> J2SE.
I concur. JavaMail is fairly fundamentally broken (as described above)
and what's needed is a better implementation. However, it doesn't
preclude a set of JavaMail-esque wrappers to facilitate interfaces by
those that are expecting it, but the preference would be to provide a
cleaner implementation.
Maillet support would be great, and one thing I don't think any other
J2EE server supports is a Mail-request based protocol, to allow (for
example) JMS to be sent over the top of SMTP, or trigger incoming mails.
Anyone know why the Maillet API didn't subclass Servlet, BTW? I'd have
thought that
public class Maillet extends GenericServlet {
public void service(SMTPRequest request, SMTPResponse) throws
ServletException, IOEXcception {
}
}
would have been a really good way to handle incoming SMTP messages
(viewing the Request/Response pair as a 'channel' rather than a one-off
HTTP input/output).
Alex.
RE: [JavaMail] Re: Geronimo standard Sun-API jars
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny wrote:
> Alex,
> > So we could use another implementation but provide a JavaMail API for
> > it in order to work. How we could do that with the issues re: Sessions
> > is a bit more problematic.
> the problem is that there is a lot of code related to Mime parsing and
> Address validation needed to conform to the RFC's in javaMail, there are a
> lot of mail RFC's (http://james.apache.org/rfclist.html) and they would
> require a lot of work to re-implement.
> I'd be very wary about starting down the road of an Apache clone of
javaMail
> unless it really offers serious advantages.
On this subject, and several others, there is talk with Sun. Let's please
just focus on what is here for now, and give Sun some time to respond.
Everyone wants to move a lot faster than Sun is likely to do. :-)
--- Noel
RE: [JavaMail] Re: Geronimo standard Sun-API jars
Posted by "Noel J. Bergman" <no...@devtech.com>.
> o Easier API to use to generate/send mails
> o Less global configuration settings
> o Conformant JavaBeans representation of MimeMessage
> o Use of Mail.getAttachment() to facilitate attachments, rather than
> presenting the low-level layer of how they are transmitted in MIME
> Multipart formats
> I've got an implementation of Transport kicking around from before that
> I can donate to the project
The appropriate place would be James (james.apache.org), and we'd be willing
to give it a look if it provides substantial benefits to our server.
--- Noel
RE: [JavaMail] Re: Geronimo standard Sun-API jars
Posted by Danny Angus <da...@apache.org>.
Alex,
> Part of the JavaMail implementation conforms to the RFCs, yes, but that
> doesn't specifically negate having other implementations that also
> conform to the RFCs.
If you're talking about protocols, I agree, but if you're talking about Mime
(RFC 2048 et-al) and Message (RFC 822 et-al) these aren't implemented in the
refrence implementation but directly by the API, my original point.
It is this fact, rather than the possibly better option whereby they would
be marked in the API by interfaces and implemented in the RI
which makes me wonder if it is worth the effort of writing coles simply to
benefit from the ASFL.
Don't forget this excercise should not permit the extension of these classes
to include new functionality, any new functionality you did provide would
not be portable as it would not for part of the published javaMail API.
> The APIs don't, in themselves, provide the conformance. The
> implementation (com.sun...) packages provide the conformance/validation.
Actually they do, for Message and Mime related classes the implementation of
the RFC's *is* coded directly into the javax.mail packages.
It is possible to alter the performance and behavour of these classes using
the normal techniques of inheritance and overriding without having to go the
extreme length of writing clones of the classes and forcing a namespace
conflict with java.mail in order to have *your* methods invoked.
> In any case, the API for JavaMail tends to be bogged down with
> low-level representations (such as MimeBodyPart)
I agree with that, IMO there sould be a cleaner distinction between API
interfaces and implementations and I often wonder why Sun decided to put so
much implementation directly into the API, and not seperated into API and
RI.
> when it could present
> a more unified interface such as getAttachment().
MimeMessage.getAttachement() is very ,limiting and makes a great deal of
assumptions about the uses being made of the content.
Mime is a recursive format, and is supported in JavaMail by recursive
methods for parsing it, if you want/need getAttachements() functionality you
should write a Mime toolkit which would use the javaMail Mime parsing
methods to extract the data you require.
This would form part of another product, *we* could never add it to the API,
only Sun can do that.
> IMHO the JavaMail
> provides a low-level representation, which is less useful for
> developers wanting to send/receive mail.
It is also less useful for server applications owing to a number of initial
assumptions which seem to have coloured the architecture to focus on mail
clients.
> > I don't believe that cloning javaMail would give anyone much
> > opportunity to
> > add functionality to the API, we're simply talking about cloning it not
> > extending it.
>
> I was talking about an extended Mail API set, that provided a JavaMail
> API to allow legacy systems to use it as well. Having had problems with
> JavaMail (as above) I wanted to try and create an implementation to
> address some of those issues.
An extended Mail API is not the same thing (see above) as rewriting the
javax.mail packages for licence convenience.
If you want to address these issues I would most strongly suggest that you
should be considering a creating seperate library of classes which extend
javaMail classes to provide the utility you require.
It is an unfortuante fact that many people feel that JavaMail is inadequate
in one way or another, but unless you can bend Sun to your will it is
unlikely that that will change, and likewise it is not possible to re-create
javaMail in any way other than supporting the current classes and methods.
If you were to do so you would no longer have packages which were
interchangeable with javaMail.
> Part of the problems with
> JavaMail are the non-trivial use of mail attachments, and the fact that
> they are also non-JavaBean compliant means that you can't easily use
> JavaBean systems with Mail messages. [I wrote a JavaMail-based Web
> client last week, and discovered that using JSTL I could say
> ${message.subject} but not ${message.content} because the MimeMessage
> doesn't conform to the JavaBean spec, despite there being a
> message.getContent() method)
This is an issue you need to raise with the javaMail developers, I don't see
how you can fix this independantly as to do so would *by definition* be to
create a different product, because javaMail would no longer be usable by
anything that uses your new functionality.
What do you believe MimeMessagegetContent() should return if not an Object?
Mime is capable of containing, recursively, a limitless number of
content-types, to make an arbitrary decision about the specific use to which
any part of any multipart message is being put doesn't make sense, in order
to make any sense of this method you have to know the content-type and make
some kind of handling decision.
It is possible to make a much simpler Mime API which makes these
assumptions, but I believe that the price of this simplicity is that it
won't perform correctly in every case.
I can see how Sun could possibly have made a less convoluted job of
javaMail, but Mime is a PITA in any language and any Mime API is bound to
reflect that if it is doing the job properly.
> > It isn't possible for *us* to extend the specification either, we're
> > not
> > Sun.
>
> Nor was I suggesting that we should -- I was suggesting a replacement
> with a JavaMail API layer to provide backward compatibility.
But what benefit would the replacement bring? anyone using it's "advanced"
features would no longer be able to use javaMail.
On the other hand providing a seperate set of javaMail extensions would
allow everyone to continue to use javaMail.
In the later case, and to return to my original point, is there anything to
be gained by cloning javaMail?
> I'll take this discussion over to the JAMES team, and hopefully then
> ApacheJ2EE and JAMES will move in the right direction.
Very good!, see you there. :-)
d.
Re: [JavaMail] Re: Geronimo standard Sun-API jars
Posted by Alex Blewitt <Al...@ioshq.com>.
On Friday, Aug 8, 2003, at 23:18 Europe/London, Danny Angus wrote:
> Alex,
>
>>> The problem is that there is a lot of code related to Mime parsing
>>> and
>>> Address validation needed to conform to the RFC's in javaMail, there
>>> are a
>>> lot of mail RFC's (http://james.apache.org/rfclist.html) and they
>>> would
>>> require a lot of work to re-implement.
>>
>> They aren't a requirement of JavaMail; they are a requirement of
>> SMTP/MIME and related RFCs. It just so happens that JavaMail also uses
>> them.
>
> I hope you're not seriously suggesting that it would be possible,
> never mind
> whether or not it is a good idea, to create a mail application which
> doesn't
> conform to the relevant RFC's.
No, the original mail message suggested that there were a lot of RFCs
implemented in JavaMail and seemed to suggest that they were specific
to JavaMail. I failed to say concisely that the RFCs were not just
JavaMail, they were generic mail RFCs that should be in other
implementations whatever flavour of mail API it was.
> If my criteria for cloning javaMail is that that action must offer
> some real
> benefit, it would be seriously negated by failure to conform to the
> relevant
> RFC's. Part of the value of javaMail is the extensive work done in
> support
> of conformance.
Part of the JavaMail implementation conforms to the RFCs, yes, but that
doesn't specifically negate having other implementations that also
conform to the RFCs.
> ... is are the abstract and concrete classes in the
> javax.mail.* packages, these are part of Suns API and it is not
> strictly
> required that an implementation re-create them. In fact the original
> reason
> mooted for doing so was simply to make them available under the ASFL.
> This
> is perhaps a worthwhile sentiment as far as the j2ee API's which are
> mainly
> interfaces are concerned, but javax.mail is mainly implementation, and
> implementation of a lot of unattractive RFC conformance to boot.
The APIs don't, in themselves, provide the conformance. The
implementation (com.sun...) packages provide the conformance/validation.
In any case, the API for JavaMail tends to be bogged down with
low-level representations (such as MimeBodyPart) when it could present
a more unified interface such as getAttachment(). IMHO the JavaMail
provides a low-level representation, which is less useful for
developers wanting to send/receive mail.
>>> I'd be very wary about starting down the road of an Apache clone of
>>> javaMail
>>> unless it really offers serious advantages.
>>
>> o Easier API to use to generate/send mails
>> o Less global configuration settings (JavaMail uses global system
>> properties)
>> o Conformant JavaBeans representation of MimeMessage
>> o Use of Mail.getAttachment() to facilitate attachments, rather than
>> presenting the low-level layer of how they are transmitted in MIME
>> Multipart formats
>
> I don't believe that cloning javaMail would give anyone much
> opportunity to
> add functionality to the API, we're simply talking about cloning it not
> extending it.
I was talking about an extended Mail API set, that provided a JavaMail
API to allow legacy systems to use it as well. Having had problems with
JavaMail (as above) I wanted to try and create an implementation to
address some of those issues.
> Any ASF clone of javax.mail would have to be a direct replacement for
> the
> original, if you want to implement extended functionality in order to
> better
> manage internal handling of the objects surely the normal use of
> inheritance
> and polymorphism is sufficient?
In the case of polymorphism, not really. Part of the problems with
JavaMail are the non-trivial use of mail attachments, and the fact that
they are also non-JavaBean compliant means that you can't easily use
JavaBean systems with Mail messages. [I wrote a JavaMail-based Web
client last week, and discovered that using JSTL I could say
${message.subject} but not ${message.content} because the MimeMessage
doesn't conform to the JavaBean spec, despite there being a
message.getContent() method)
> It isn't possible for *us* to extend the specification either, we're
> not
> Sun.
Nor was I suggesting that we should -- I was suggesting a replacement
with a JavaMail API layer to provide backward compatibility.
> Well hold on until things settle down, it all seems a bit up in the
> air here
> at the moment :-)
I'll take this discussion over to the JAMES team, and hopefully then
ApacheJ2EE and JAMES will move in the right direction.
Alex.
RE: [JavaMail] Re: Geronimo standard Sun-API jars
Posted by "Noel J. Bergman" <no...@devtech.com>.
> my sentiment would be for a asfj2ee-javamail-api.jar existing which
> contains the api and not the implementation made available.
The specification dictates if something is an interface or a class. Other
(third party) code may extend one of those standard classes. Therefore if
you don't have the right behavior in your class, that code isn't going to
work.
As has been said a couple of times by different people, Sun had no advance
notice of this project. They will need a bit of time to decide how to
participate, so let's be patient. Meanwhile, there are tons of other areas
to work on. :-)
At least that's my advice. :-)
--- Noel
RE: [JavaMail] Re: Geronimo standard Sun-API jars
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 8 Aug 2003, Danny Angus wrote:
> Alex,
>
>
> required that an implementation re-create them. In fact the original reason
> mooted for doing so was simply to make them available under the ASFL. This
> is perhaps a worthwhile sentiment as far as the j2ee API's which are mainly
> interfaces are concerned, but javax.mail is mainly implementation, and
> implementation of a lot of unattractive RFC conformance to boot.
With this education having occurred, my sentiment would be for a
asfj2ee-javamail-api.jar existing which contains the api and not the
implementation made available. Sentiment could be utterly wrong though if
it's not possible.
Hen
RE: [JavaMail] Re: Geronimo standard Sun-API jars
Posted by Danny Angus <da...@apache.org>.
Alex,
> > The problem is that there is a lot of code related to Mime parsing and
> > Address validation needed to conform to the RFC's in javaMail, there
> > are a
> > lot of mail RFC's (http://james.apache.org/rfclist.html) and they would
> > require a lot of work to re-implement.
>
> They aren't a requirement of JavaMail; they are a requirement of
> SMTP/MIME and related RFCs. It just so happens that JavaMail also uses
> them.
I hope you're not seriously suggesting that it would be possible, never mind
whether or not it is a good idea, to create a mail application which doesn't
conform to the relevant RFC's.
If my criteria for cloning javaMail is that that action must offer some real
benefit, it would be seriously negated by failure to conform to the relevant
RFC's. Part of the value of javaMail is the extensive work done in support
of conformance.
I'm *not* talking about the reference implementation of providers in the
com.sun.* packages, thats obviously a target for this effort, what I'm
talking about here is are the abstract and concrete classes in the
javax.mail.* packages, these are part of Suns API and it is not strictly
required that an implementation re-create them. In fact the original reason
mooted for doing so was simply to make them available under the ASFL. This
is perhaps a worthwhile sentiment as far as the j2ee API's which are mainly
interfaces are concerned, but javax.mail is mainly implementation, and
implementation of a lot of unattractive RFC conformance to boot.
> > I'd be very wary about starting down the road of an Apache clone of
> > javaMail
> > unless it really offers serious advantages.
>
> o Easier API to use to generate/send mails
> o Less global configuration settings (JavaMail uses global system
> properties)
> o Conformant JavaBeans representation of MimeMessage
> o Use of Mail.getAttachment() to facilitate attachments, rather than
> presenting the low-level layer of how they are transmitted in MIME
> Multipart formats
I don't believe that cloning javaMail would give anyone much opportunity to
add functionality to the API, we're simply talking about cloning it not
extending it.
Any ASF clone of javax.mail would have to be a direct replacement for the
original, if you want to implement extended functionality in order to better
manage internal handling of the objects surely the normal use of inheritance
and polymorphism is sufficient?
It isn't possible for *us* to extend the specification either, we're not
Sun.
>
> > Bearing in mind that any clone of javaMail would have to offer pretty
> > much
> > interchangeable behaviour with the official product, particularly if
> > it has
> > to pass tests, the issue of implementing the Store and Transport
> > interfaces
> > is where we should start, and quite probably end too.
>
> I've got an implementation of Transport kicking around from before that
> I can donate to the project, and I'm more than willing to give an
> implementation of JavaMail ago. But since I don't have access to the
> CVS repositories for dumping implementations, I'll have to send it as a
> pretty big patch file :-)
Well hold on until things settle down, it all seems a bit up in the air here
at the moment :-)
d.
Re: [JavaMail] Re: Geronimo standard Sun-API jars
Posted by Alex Blewitt <Al...@bandlem.com>.
> The problem is that there is a lot of code related to Mime parsing and
> Address validation needed to conform to the RFC's in javaMail, there
> are a
> lot of mail RFC's (http://james.apache.org/rfclist.html) and they would
> require a lot of work to re-implement.
They aren't a requirement of JavaMail; they are a requirement of
SMTP/MIME and related RFCs. It just so happens that JavaMail also uses
them.
> I'd be very wary about starting down the road of an Apache clone of
> javaMail
> unless it really offers serious advantages.
o Easier API to use to generate/send mails
o Less global configuration settings (JavaMail uses global system
properties)
o Conformant JavaBeans representation of MimeMessage
o Use of Mail.getAttachment() to facilitate attachments, rather than
presenting the low-level layer of how they are transmitted in MIME
Multipart formats
> Bearing in mind that any clone of javaMail would have to offer pretty
> much
> interchangeable behaviour with the official product, particularly if
> it has
> to pass tests, the issue of implementing the Store and Transport
> interfaces
> is where we should start, and quite probably end too.
I've got an implementation of Transport kicking around from before that
I can donate to the project, and I'm more than willing to give an
implementation of JavaMail ago. But since I don't have access to the
CVS repositories for dumping implementations, I'll have to send it as a
pretty big patch file :-)
Alex.
RE: [JavaMail] Re: Geronimo standard Sun-API jars
Posted by Danny Angus <da...@apache.org>.
Alex,
> So we could use another implementation but provide a JavaMail API for
> it in order to work. How we could do that with the issues re: Sessions
> is a bit more problematic.
the problem is that there is a lot of code related to Mime parsing and
Address validation needed to conform to the RFC's in javaMail, there are a
lot of mail RFC's (http://james.apache.org/rfclist.html) and they would
require a lot of work to re-implement.
I'd be very wary about starting down the road of an Apache clone of javaMail
unless it really offers serious advantages.
Bearing in mind that any clone of javaMail would have to offer pretty much
interchangeable behaviour with the official product, particularly if it has
to pass tests, the issue of implementing the Store and Transport interfaces
is where we should start, and quite probably end too.
d.
[JavaMail] Re: Geronimo standard Sun-API jars
Posted by Alex Blewitt <Al...@ioshq.com>.
> I'm currently working on a belief that J2EE implies usage of standard
> Sun
> specs. ie) it says use JavaMail rather than have a mail option. Will
> read
> through the J2EE spec more to be able to put a better input in.
I don't think it mandates the use of JavaMail for everything. However,
it does mandate that the JavaMail APIs be available to programs.
So we could use another implementation but provide a JavaMail API for
it in order to work. How we could do that with the issues re: Sessions
is a bit more problematic.
Alex.
Re: [JavaMail] J2EE Spec (Was RE: Geronimo standard Sun-API jars)
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 8 Aug 2003, Danny Angus wrote:
> Henri wrote:
>
> > I'm currently working on a belief that J2EE implies usage of standard Sun
> > specs. ie) it says use JavaMail rather than have a mail option. Will read
> > through the J2EE spec more to be able to put a better input in.
>
> Yeah I fully expect you're right about that, I just was speculating about
> what added value geronimo might offer, in any case actually implementing
> javaMail is what is required, what would be much harder would be to re-write
> javaMail simply inorder to have it available under ASFL.
My focus is definitely on the J2EE parts of Geri [Spice Girls!] and how
many of them can be common [and maybe even in Jakarta Commons, but having
them common is the main aim]. Would love a ASF-J2EE impl's section :)
Hen
[JavaMail] J2EE Spec (Was RE: Geronimo standard Sun-API jars)
Posted by Danny Angus <da...@apache.org>.
Henri wrote:
> I'm currently working on a belief that J2EE implies usage of standard Sun
> specs. ie) it says use JavaMail rather than have a mail option. Will read
> through the J2EE spec more to be able to put a better input in.
Yeah I fully expect you're right about that, I just was speculating about
what added value geronimo might offer, in any case actually implementing
javaMail is what is required, what would be much harder would be to re-write
javaMail simply inorder to have it available under ASFL.
d.
RE: Geronimo standard Sun-API jars
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 8 Aug 2003, Danny Angus wrote:
> Henri wrote:
>
> > The first thing I'm looking for from Geronimo is not a working J2EE
> > server, but a redistributable version of:
> >
> > javamail.jar
>
> I belive that it has been determined that JavaMail is redistributable when
> packaged with it's licence, and whatever else.
>
> It is not a simple matter, for JavaMail, of typing interfaces in from the
> javadocs.
> Unfortunately the inheritance root of most of JavaMail are abstract classes,
> not interfaces, and in addition to this there are some key classes which are
> concrete, such as MimeMessage.
>
> ....
>
> I believe that the Mailet API is, for mail, much more closely aligned with
> the principles of J2EE than javaMail is, which probably really belongs in
> J2SE.
I'm currently working on a belief that J2EE implies usage of standard Sun
specs. ie) it says use JavaMail rather than have a mail option. Will read
through the J2EE spec more to be able to put a better input in.
Hen
RE: Geronimo standard Sun-API jars
Posted by Danny Angus <da...@apache.org>.
Henri wrote:
> The first thing I'm looking for from Geronimo is not a working J2EE
> server, but a redistributable version of:
>
> javamail.jar
I belive that it has been determined that JavaMail is redistributable when
packaged with it's licence, and whatever else.
It is not a simple matter, for JavaMail, of typing interfaces in from the
javadocs.
Unfortunately the inheritance root of most of JavaMail are abstract classes,
not interfaces, and in addition to this there are some key classes which are
concrete, such as MimeMessage.
None of this is beyond the scope of a re-implementation, but it isn't
trivial and questions would have to be answered about the value of this
effort given that JavaMail is, by Sun's own admission a client-side API not
a server one, and that the James project have already uncovered a number of
gotchas for server development caused by this client focus.
Just for instance javaMail supports outgoing SMTP and incoming POP and IMAP
but not the converse of each, and infact the API refers to incoming
collection protocol handlers as "Stores", and outgoing protocol handlers as
"Transports", a freudian distinction which clearly marks this down, in my
mind at least, as an out-and-out client product.
It is also the case that a single global mail "session" exists in a vm,
again underlining the assumption by Sun that any vm running javaMail will
most likely be doing so as a single user mail client, not as a multi user
server.
None of these things stop James from making good use of javaMail, and we are
vaguely planning to do more, Sun distributes an RI for several protocol
handlers (Transports and Stores) and James would like to have greater
control over some and some completely new ones, so there _is_ scope, will
and expertise available for implementing javaMail in geronimo but IMO there
are serious caveats surrounding the value of re-implementing javaMail in
it's entirety just for licencing convenience.
The best thing we could do as a community in relation to mail, in my very
humble opinion, would be to extend the API in geronimo to provide the
framework for server functionality which we miss, and to include an
implementation of the Apache Mailet API, but this would depend heavily upon
the direction the project takes with respect to whether geronimo is (or
tries to be) the J2EE RI or just a top quality product.
I believe that the Mailet API is, for mail, much more closely aligned with
the principles of J2EE than javaMail is, which probably really belongs in
J2SE.
d.