Announcement Announcement Module
Collapse
No announcement yet.
problem with javax.mail packages Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • problem with javax.mail packages

    When I try to use org.springframework.mail.javamail.JavaMailSenderIm pl in my applicationContext class I keep get the following error when starting the application :

    java.lang.NoClassDefFoundError: javax/mail/MessagingException

    although I imported the com.springsource.javax.mail bundle in my MANIFEST.MF, I tried removing the Import-Bundle and use the Import-Package (javax.mail) but I keep getting the error...

    any ideas what could be wrong?

    Code:
    Manifest-Version: 1.0
    Module-Type: Web
    Web-ContextPath: MailAdministrator
    Bundle-SymbolicName: MailAdministratorDM
    Bundle-Version: 1.0.1
    Bundle-ManifestVersion: 2
    Bundle-Name: MailAdministratorDM Bundle 
    Import-Library: org.springframework.spring;version="[2.5.6.A,2.5.6.A]"
    Import-Bundle: 
     com.springsource.org.hibernate;version="[3.2.6.ga,3.2.6.ga]",
     be.company.common;version="[1.0.0,1.0.0]",
     com.springsource.org.apache.struts;version="[1.2.9,1.2.9]",
     com.springsource.javax.servlet.jsp;version="[2.1.0,2.1.0]",
     com.springsource.javax.servlet;version="[2.5.0,2.5.0]",
     com.springsource.javax.mail,
     org.springframework.context.support;version="[2.5.6.A,2.5.6.A]",
     org.springframework.context;version="[2.5.6.A,2.5.6.A]",
     com.springsource.net.sf.navigator;version="[2.4.3,2.4.3]",
     com.springsource.org.apache.commons.beanutils;version="[1.7.0,1.7.0]",
     com.springsource.org.apache.commons.lang;version="[2.4.0,3.0.0]",
     com.springsource.org.apache.commons.validator;version="[1.1.4,1.1.4]",
     com.springsource.org.apache.velocity;version="[1.4.0,2.0.0]",
     org.springframework.struts;version="[2.5.6.A,2.5.6.A]",
     com.springsource.org.apache.velocity.tools.view;version="[1.4.0,1.4.0]",
     com.springsource.org.apache.commons.pool;version="[1.3.0,1.3.0]",
     com.springsource.jt400,
     com.springsource.org.apache.commons.dbcp,
     com.springsource.net.sf.cglib;version="[2.1.3,2.1.3]",
     com.springsource.jcifs,
     com.springsource.javax.servlet.jsp.jstl;version="[1.2.0,1.2.0]"
    stacktrace:

    Code:
    org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'mailSender' defined in URL [bundleentry://108/META-INF/spring/application-context.xml]: Instantiation of bean failed; nested exception is java.lang.NoClassDefFoundError: javax/mail/MessagingException
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:883)
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:839)
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:440)
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
    	at java.security.AccessController.doPrivileged(Native Method)
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
    	at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
    	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
    	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
    	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
    	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)
    	at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:288)
    	at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:145)
    	at com.springsource.server.kernel.dm.ContextPropagatingTaskExecutor$2.run(ContextPropagatingTaskExecutor.java:82)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
    	at java.lang.Thread.run(Thread.java:595)
    Caused by: java.lang.NoClassDefFoundError: javax/mail/MessagingException
    	at java.lang.Class.getDeclaredConstructors0(Native Method)
    	at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
    	at java.lang.Class.getConstructor0(Class.java:2671)
    	at java.lang.Class.getDeclaredConstructor(Class.java:1953)
    	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:54)
    	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:877)
    	... 18 more
    
    [2009-01-12 10:05:58.083] onnection(2)-10.35.205.1 <SPDE0011E> Deployment of 'MailAdministratorDM' version '1.0.1' failed.
    Last edited by Cuball; Jan 12th, 2009, 03:16 AM. Reason: MANIFEST.MF + Stacktrace added

  • #2
    It seems that you need to add JavaMail to your classpath : http://java.sun.com/products/javamai...ads/index.html

    Comment


    • #3
      I did import the bundle
      Code:
      javax.mail
      org.springframework.context.support
      these should contain the required classes...

      Comment


      • #4
        There's no reason why this should not work. I've just tried a basic simple single-bundle application that create a JavaMailSenderImpl in its application context and it doesn't exhibit the problem that you're seeing.

        There must be some subtle difference in your application that's causing the problem. If you'd like us to look into this further please open a JIRA, attaching an application that reproduces the problem.

        Thanks,
        Andy

        Comment


        • #5
          I'm experiencing the same problem. Cuball, did you ever find a fix? Here are my relevant configs followed by the stack trace:

          Code:
          <?xml version="1.0" encoding="UTF-8"?>
          <beans xmlns="http://www.springframework.org/schema/beans"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:osgix="http://www.springframework.org/schema/osgi-compendium"
             xmlns:ctx="http://www.springframework.org/schema/context"
             xmlns:osgi="http://www.springframework.org/schema/osgi"
             xsi:schemaLocation="
          	http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
          	http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
          	http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi.xsd
          	http://www.springframework.org/schema/osgi-compendium http://www.springframework.org/schema/osgi-compendium/spring-osgi-compendium.xsd">
          
          	<osgi:service ref="emailerService" interface="org.example.emailer.EmailerService" />
          	<osgi:reference id="personDao" interface="org.example.ldap.person.PersonDao" />
          
          	<bean id="emailerService" class="org.example.emailer.impl.EmailerServiceImpl">
          		<osgix:managed-properties persistent-id="org.example.emailer.sender" update-strategy="container-managed"/>
          		<property name="mailSender" ref="mailSender" />
          		<property name="personDao" ref="personDao" />
          		<property name="senderAddress" value="[email protected]" />
          	</bean>
          
          	<bean id="mailSender" class="org.springframework.mail.javamail.JavaMailSenderImpl">
          		<osgix:managed-properties persistent-id="org.example.emailer.smtp" update-strategy="container-managed"/>
            		<property name="host" value="smtp.example.org"/>
          	</bean>
          </beans>
          Code:
          Manifest-Version: 1.0
          Bundle-Version: 0.0.1
          Bundle-Name: Email Service
          Bundle-ManifestVersion: 2
          Bundle-SymbolicName: org.example.emailer
          Export-Package: org.example.emailer;version="0.0.1"
          Application-TraceLevels: org.example.emailer.*=verbose
          Import-Package: org.example.ldap.person;version="[0.0.1,0.0.1]",
           org.slf4j;version="[1.5.6,1.5.6]"
          Import-Library: org.springframework.spring;version="[2.5.6.A,2.5.6.A]"
          Import-Bundle: com.springsource.javax.mail;version="[1.4.1,1.4.1]"
          Code:
          org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'mailSender' defined in URL [bundleentry://171.fwk16675983/META-INF/spring/module-osgi.xml]: Instantiation of bean failed; nested exception is java.lang.NoClassDefFoundError: javax/mail/MessagingException
          	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:883)
          	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:839)
          	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:440)
          	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
          	at java.security.AccessController.doPrivileged(Native Method)
          	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
          	at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
          	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
          	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
          	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
          	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
          	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
          	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)
          	at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:69)
          	at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:355)
          	at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
          	at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320)
          	at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:136)
          	at com.springsource.kernel.dmfragment.internal.ContextPropagatingTaskExecutor$2.run(ContextPropagatingTaskExecutor.java:82)
          	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
          	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
          	at java.lang.Thread.run(Thread.java:619)
          Caused by: java.lang.NoClassDefFoundError: javax/mail/MessagingException
          	at java.lang.Class.getDeclaredConstructors0(Native Method)
          	at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
          	at java.lang.Class.getConstructor0(Class.java:2699)
          	at java.lang.Class.getDeclaredConstructor(Class.java:1985)
          	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:54)
          	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:877)
          	... 21 more
          Caused by: com.springsource.kernel.osgi.framework.ExtendedClassNotFoundException: javax.mail.MessagingException in KernelBundleClassLoader: [bundle=org.springframework.context.support_2.5.6.A]
          	at com.springsource.kernel.osgi.framework.equinox.KernelBundleClassLoader.loadClass(KernelBundleClassLoader.java:135)
          	at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
          	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
          	... 27 more
          Caused by: java.lang.ClassNotFoundException: javax.mail.MessagingException
          	at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:489)
          	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405)
          	at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393)
          	at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:88)
          	at com.springsource.kernel.osgi.framework.equinox.KernelBundleClassLoader.loadClass(KernelBundleClassLoader.java:133)
          	... 29 more

          Comment


          • #6
            Looking at your stack trace you can see which bundle's classloader was attempting to load a javax.mail class:

            Code:
            Caused by: com.springsource.kernel.osgi.framework.ExtendedClassNotFoundException: javax.mail.MessagingException in KernelBundleClassLoader: [bundle=org.springframework.context.support_2.5.6.A]
            You can see from this that Spring's context support bundle wasn't able to load the javax.mail.MessagingException class. The context support bundle contains an optional import for javax.mail. My guess would be that the context support bundle isn't wired to the javax.mail bundle, possibly because javax.mail wasn't available when the context support bundle was resolved. If that's the case, starting dm Server with the javax.mail bundle in the repository should fix the problem. If it doesn't, I'd recommend taking a look at the wiring using the Telnet console, available by default on port 2401.

            Comment


            • #7
              That was a point in the right direction. I finally found a fix, but it doesn't really make sense. Unfortunately I don't have time to really investigate. Anyway, here's what I did in case anyone else runs into this.

              The bundle for Spring context support (org.springframework.context.support-2.5.6.A in my case) has optional imports for javax.mail and javax.mail.internet:

              Code:
              javax.mail;version="[1.4.0, 2.0.0)";resolution:=optional,javax.mail.internet;version="[1.4.0, 2.0.0)";resolution:=optional
              These two packages are exported by the com.springsource.javax.mail bundle, which is provided in repository/ext. I verified that this bundle was loaded properly by going in to equinox over telnet. However, the Spring context support bundle was *not* importing them - again verified by telneting into equinox.

              The "hack" was to change the manifest for org.springframework.context.support-2.5.6.A to de-version the two mail packages and make them required:

              Code:
              javax.mail,javax.mail.internet
              For whatever reason, the context support bundle will now correctly import those packages and then everyone else is happy. Doesn't make sense why this altered manifest would work over the original. Anyone have any ideas?

              Comment


              • #8
                An ever so slightly better method of achieving the same goal is to copy the context.support jar into the resources folder of your bundle, add it to the classpath of the bundle, remove all entries relating to it from the manifest and manually add the following entry to the manifest:
                Bundle-ClassPath: ., org.springframework.context.support-X.X.X.jar

                What this does is bundles the jar up with your bundle; it will now successfully resolve the references to the missing javax.mail items, since they are being imported to your bundle via the relevant Import-Bundle entry, all without having to touch the manifest inside the context.support jar. An added bonus is that only the offending bundle is affected, thereby minimising potential problems in other bundles.

                HTH. Cheers,
                Skippy

                Comment


                • #9
                  I have the same problem.. unfortunately I'm not a spring deep expert. Can you please explain step by step how to fix the problem??
                  Many thanks


                  Originally posted by Skippy View Post
                  An ever so slightly better method of achieving the same goal is to copy the context.support jar into the resources folder of your bundle, add it to the classpath of the bundle, remove all entries relating to it from the manifest and manually add the following entry to the manifest:
                  Bundle-ClassPath: ., org.springframework.context.support-X.X.X.jar

                  What this does is bundles the jar up with your bundle; it will now successfully resolve the references to the missing javax.mail items, since they are being imported to your bundle via the relevant Import-Bundle entry, all without having to touch the manifest inside the context.support jar. An added bonus is that only the offending bundle is affected, thereby minimising potential problems in other bundles.

                  HTH. Cheers,
                  Skippy

                  Comment


                  • #10
                    Deib, it should be perfectly possible to make use of javax.mail, without having to modify any Spring bundles, and without having to package the context support bundle inside your own bundle.

                    If you post some details of your application and its bundles or, ideally, open a JIRA attaching the application that your having problems with, I'll take a look. Hopefully we'll be able to get to the bottom of the problem and fix it, without you having to use either of the workarounds described above.

                    Comment


                    • #11
                      Andy,

                      The problem doesn't appear to be one of configuration, but rather that the context.support bundle doesn't recognise that the mail jars are required by a particular project (because these jars are marked as optional in the context.support bundle's manifest). So they don't get resolved / started or whatever.

                      Is there a way of forcing the context.support bundle to realise that the mail jars ARE actually required?

                      Cheers,
                      Skippy

                      Comment


                      • #12
                        As the imports are optional, the OSGi resolver can choose the drop the imports, if no exporting bundle is available, or if it can't wire to the exports for some reason.

                        During startup, dm Server's provisioning support will attempt to satisfy every optional import, i.e. when the context support bundle is installed, dm Server will detect that imports the javax.mail package, and will look in its repository for a bundle which exports this package. If such a bundle is found, it will be installed, and the resolver should then wire the context support bundle to the javax.mail bundle.

                        The only way that you can force a import to be wired is by making it mandatory, i.e. removing resolution:=optional from the import. In this case, if the import can't be wired to an export, the importing bundle will fail to resolve.

                        It would be interesting to know if the javax.mail bundle gets installed, but the context.support bundle doesn't wire to it, or if dm Server doesn't install the bundle at all.

                        Comment


                        • #13
                          Okay. I've done some experiments and this is what I've found:

                          The initial NCDFE on javax/mail/MessagingException seems to be being caused when javax.activation is missing from the Import-Package section of the manifest. I noticed that DM Server wasn't happy if I imported this as a bundle - it had to be in the Import-Package section - and I also had to manually download the activation jar (version 1.1.0), because it is not included in the DM Server repository as standard (whereas mail v1.4.0 is).

                          So, I seem to be able to get it up and running if I include the following:
                          Import-Package: javax.activation[1.1.0,1.1.0]
                          Import-Bundle: javax.mail[1.4.0,1.4.0]
                          Import-Library: org.springframework.spring[2.5.6.A,2.5.6A]

                          But I would like to use the latest version of the mail package, so I downloaded mail v1.4.1 and activation v1.1.1 to the DM Server repository. Without changing anything in the manifest for my project (i.e. it's still got the activation v1.1.0 and mail v1.4.0 entries from above), I now get a 'Uses Conflict: Import-Package: javax.mail; version="1.4.0"' when trying to deploy the exact same project, and the entire deployment falls over in a heap.

                          Why?

                          Cheers,
                          Skippy
                          Last edited by Skippy; Jun 8th, 2009, 07:55 AM.

                          Comment


                          • #14
                            My previous post might not have been so accurate after all: I'm now running into the dreaded "No object DCH for MIME type..." exception, which Oleg Zhurakousky describes in detail here when using the suggested imports.

                            I think that the original problem may have actually been because I (inadvertently) had both activation v1.1.0 and v1.1.1 in my deployment: v1.1.0 is included as part of the server, while I had downloaded 1.1.1 from the S2BR in order to try to use mail v1.4.1...

                            Cheers,
                            Skippy

                            Comment


                            • #15
                              That's really useful information, thanks.

                              javax.activation is an interesting bundle / package as it's possibly available from the JRE, depending on which version of Java you're using, and which version of activation you want to use.

                              In dm Server 1.0, where we support Java 5 and Java 6, we package the 1.1.0 version of the javax.activation bundle in the lib directory, and exports its packages from the system bundle. When you're running on Java 6 the activation types in the lib directory will be ignored, as those in the JRE will take precedence.

                              In dm Server 2.0, where we support Java 6, we simply export the javax.activation package from the system bundle, thereby making the javax.activation types that are in the JRE available to bundles deployed in dm Server.

                              My guess would be that your uses problem has occurred because you have one or more bundles wired to javax.activation from the system bundle, and one or more bundles wired to your 1.1.1 javax.activation bundle which makes the javax.activation types used by these bundles incompatible with each other.

                              I'd like to get to the bottom of your situation and, hopefully, offer some advice about the best way to make use of javax.activation 1.1.1. Can you let me know what version of dm Server you're using, and if you're on dm Server 1.0.x, what version of Java you're running with.

                              Thanks,
                              Andy.

                              Comment

                              Working...
                              X