You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Rick McGuire (JIRA)" <de...@geronimo.apache.org> on 2006/10/16 12:48:34 UTC

[jira] Created: (GERONIMO-2498) Geronimo should use the full javamail uber jar instead of just the spec jar + provider jar.

Geronimo should use the full javamail uber jar instead of just the spec jar + provider jar.
-------------------------------------------------------------------------------------------

                 Key: GERONIMO-2498
                 URL: http://issues.apache.org/jira/browse/GERONIMO-2498
             Project: Geronimo
          Issue Type: Improvement
      Security Level: public (Regular issues)
          Components: mail
    Affects Versions: 1.2
            Reporter: Rick McGuire
         Assigned To: Rick McGuire
            Priority: Minor
             Fix For: 1.2


Unlike the Sun version of javamail, the Geronimo version is split into a spec jar and a provider jar.  This has caused numerous problems with users attempting to use javamail from their applications.  Many base components have a javamail spec dependency, which causes the javamail api classes to be loaded, but not the provider classes.  The first hint of a problem is usually a NoSuchProvider exception thrown when trying to create an smtp transport instance.  This generally takes some time to sort out.  And even once the dependency is added, there has been at least one occasion where it was necessary to change the application to explicitly set the context classloader before creating the Transport, thus requiring a change from an application that worked on other servers.  Again, this was caused by having spec and provider jars managed by different classloader instances. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Updated: (GERONIMO-2498) Geronimo should use the full javamail uber jar instead of just the spec jar + provider jar.

Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/GERONIMO-2498?page=all ]

Rick McGuire updated GERONIMO-2498:
-----------------------------------

    Fix Version/s: Wish List
                       (was: 1.2)

> Geronimo should use the full javamail uber jar instead of just the spec jar + provider jar.
> -------------------------------------------------------------------------------------------
>
>                 Key: GERONIMO-2498
>                 URL: http://issues.apache.org/jira/browse/GERONIMO-2498
>             Project: Geronimo
>          Issue Type: Improvement
>      Security Level: public(Regular issues) 
>          Components: mail
>    Affects Versions: 1.2
>            Reporter: Rick McGuire
>         Assigned To: Rick McGuire
>            Priority: Minor
>             Fix For: Wish List
>
>
> Unlike the Sun version of javamail, the Geronimo version is split into a spec jar and a provider jar.  This has caused numerous problems with users attempting to use javamail from their applications.  Many base components have a javamail spec dependency, which causes the javamail api classes to be loaded, but not the provider classes.  The first hint of a problem is usually a NoSuchProvider exception thrown when trying to create an smtp transport instance.  This generally takes some time to sort out.  And even once the dependency is added, there has been at least one occasion where it was necessary to change the application to explicitly set the context classloader before creating the Transport, thus requiring a change from an application that worked on other servers.  Again, this was caused by having spec and provider jars managed by different classloader instances. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Updated: (GERONIMO-2498) Geronimo should use the full javamail uber jar instead of just the spec jar + provider jar.

Posted by "Christopher M. Cardona (JIRA)" <ji...@apache.org>.
     [ http://issues.apache.org/jira/browse/GERONIMO-2498?page=all ]

Christopher M. Cardona updated GERONIMO-2498:
---------------------------------------------

    Affects Version/s: 2.0-M1

> Geronimo should use the full javamail uber jar instead of just the spec jar + provider jar.
> -------------------------------------------------------------------------------------------
>
>                 Key: GERONIMO-2498
>                 URL: http://issues.apache.org/jira/browse/GERONIMO-2498
>             Project: Geronimo
>          Issue Type: Improvement
>      Security Level: public(Regular issues) 
>          Components: mail
>    Affects Versions: 1.2, 2.0-M1
>            Reporter: Rick McGuire
>         Assigned To: Rick McGuire
>            Priority: Minor
>             Fix For: Wish List
>
>
> Unlike the Sun version of javamail, the Geronimo version is split into a spec jar and a provider jar.  This has caused numerous problems with users attempting to use javamail from their applications.  Many base components have a javamail spec dependency, which causes the javamail api classes to be loaded, but not the provider classes.  The first hint of a problem is usually a NoSuchProvider exception thrown when trying to create an smtp transport instance.  This generally takes some time to sort out.  And even once the dependency is added, there has been at least one occasion where it was necessary to change the application to explicitly set the context classloader before creating the Transport, thus requiring a change from an application that worked on other servers.  Again, this was caused by having spec and provider jars managed by different classloader instances. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Closed: (GERONIMO-2498) Geronimo should use the full javamail uber jar instead of just the spec jar + provider jar.

Posted by "Rick McGuire (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick McGuire closed GERONIMO-2498.
----------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: Wish List)
                   2.0

> Geronimo should use the full javamail uber jar instead of just the spec jar + provider jar.
> -------------------------------------------------------------------------------------------
>
>                 Key: GERONIMO-2498
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-2498
>             Project: Geronimo
>          Issue Type: Improvement
>      Security Level: public(Regular issues) 
>          Components: mail
>    Affects Versions: 1.2, 2.0-M1
>            Reporter: Rick McGuire
>            Assignee: Rick McGuire
>            Priority: Minor
>             Fix For: 2.0
>
>
> Unlike the Sun version of javamail, the Geronimo version is split into a spec jar and a provider jar.  This has caused numerous problems with users attempting to use javamail from their applications.  Many base components have a javamail spec dependency, which causes the javamail api classes to be loaded, but not the provider classes.  The first hint of a problem is usually a NoSuchProvider exception thrown when trying to create an smtp transport instance.  This generally takes some time to sort out.  And even once the dependency is added, there has been at least one occasion where it was necessary to change the application to explicitly set the context classloader before creating the Transport, thus requiring a change from an application that worked on other servers.  Again, this was caused by having spec and provider jars managed by different classloader instances. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (GERONIMO-2498) Geronimo should use the full javamail uber jar instead of just the spec jar + provider jar.

Posted by "Matt Hogstrom (JIRA)" <ji...@apache.org>.
    [ http://issues.apache.org/jira/browse/GERONIMO-2498?page=comments#action_12449802 ] 
            
Matt Hogstrom commented on GERONIMO-2498:
-----------------------------------------

Rick...should this be moved out of 1.2?  If so could you assign the target version?  I assume 2.0

> Geronimo should use the full javamail uber jar instead of just the spec jar + provider jar.
> -------------------------------------------------------------------------------------------
>
>                 Key: GERONIMO-2498
>                 URL: http://issues.apache.org/jira/browse/GERONIMO-2498
>             Project: Geronimo
>          Issue Type: Improvement
>      Security Level: public(Regular issues) 
>          Components: mail
>    Affects Versions: 1.2
>            Reporter: Rick McGuire
>         Assigned To: Rick McGuire
>            Priority: Minor
>             Fix For: 1.2
>
>
> Unlike the Sun version of javamail, the Geronimo version is split into a spec jar and a provider jar.  This has caused numerous problems with users attempting to use javamail from their applications.  Many base components have a javamail spec dependency, which causes the javamail api classes to be loaded, but not the provider classes.  The first hint of a problem is usually a NoSuchProvider exception thrown when trying to create an smtp transport instance.  This generally takes some time to sort out.  And even once the dependency is added, there has been at least one occasion where it was necessary to change the application to explicitly set the context classloader before creating the Transport, thus requiring a change from an application that worked on other servers.  Again, this was caused by having spec and provider jars managed by different classloader instances. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira