problem with javax.mail packages

[Skippy]

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

[Andy Wilkinson]

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.

[Skippy]

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

[Skippy]

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

[Andy Wilkinson]

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.

[Skippy]

Hi Andy,

I'm currently running on DM Server 1.0.1.RELEASE, with JRE 1.6.0 u07 (yes, I know there are later versions of both available, but that's where I started and haven't needed to change - yet!).

Cheers,
Skippy

[Andy Wilkinson]

Hi Skippy,

Thanks for the information.

I've spent a bit of time looking at this, and have discovered that we've made a mistake with the version of javax.activation that we package, and that we export from the system bundle. I had thought that it was version 1.1.0 that's part of SE 6 but, have learned that it's 1.1.1. I've opened DMS-919 to fix this.

You may like to try the likely fix - it's pretty straightforward, especially as you're on Java 6. All you need to do is update the java6-server.profile file to export javax.activation at version 1.1.1, rather than version 1.1.0.

Here's the diff for the profile:

- javax.activation;version="1.1.0",\
+ javax.activation;version="1.1.1",\

For completeness, if anyone wishes to try this on Java 5, you would have to make the same change to the java5-server.profile and replace the javax.activation 1.1.0 bundle in the lib directory with javax.activation 1.1.1.

I'm hopeful that this change will fix your problem, and allow you to make use of javax mail 1.4.1. It'd be great if you could try it out, and let me know how you get on.

Thanks,
Andy

[Skippy]

Hi Andy,

Many thanks for looking into this.

I'd love to say that it worked for me, but it doesn't appear to have done so - perhaps because I'm still using DM Server 1.0.1? Anyway, here's what I did and the results it gave:

I edited the java6-server.profile file (in %SERVER_HOME%/lib) as per your instructions, downloaded javax.mail v1.4.1 and updated my manifest to import bundle javax.mail 1.4.1. I completely rebuilt my app, restarted the server and redeployed the app. When I tried sending mail I got the "No object DCH for MIME type text/html" exception.

I noted when editing the profile file that the activation version in the same directory was at 1.1.0. I tried replacing it with 1.1.1 (having downloaded it from the S2BR) and now the server won't start, complaining that the "activation-1.1.0.jar which is referenced by the classpath, does not exist". Does this mean I should have restarted Eclipse too?

Cheers,
Skippy

[Andy Wilkinson]

Sorry to hear that didn't solve your problem and thanks for trying out the change. I think we're making progress, as everything now resolves using activation 1.1.1.

As for your two problems, let's take the easy one first

I noted when editing the profile file that the activation version in the same directory was at 1.1.0. I tried replacing it with 1.1.1 (having downloaded it from the S2BR) and now the server won't start, complaining that the "activation-1.1.0.jar which is referenced by the classpath, does not exist". Does this mean I should have restarted Eclipse too?

The run configuration that's created by dm Server tools includes references to all of the JARs in the lib directory. You should be able to fix this, either by modifiying the configuration, or by deleting your existing targetted runtime, and recreating it.

I edited the java6-server.profile file (in %SERVER_HOME%/lib) as per your instructions, downloaded javax.mail v1.4.1 and updated my manifest to import bundle javax.mail 1.4.1. I completely rebuilt my app, restarted the server and redeployed the app. When I tried sending mail I got the "No object DCH for MIME type text/html" exception.

This one's a little harder. I think I'll need to spend some time trying to reproduce this so that I can debug javax.mail's behaviour. If you would be happy to attach your application that reproduces the problem then that would be a big help.

Thanks again,
Andy

[Skippy]

Well, yes...

The run configuration that's created by dm Server tools includes references to all of the JARs in the lib directory. You should be able to fix this, either by modifiying the configuration, or by deleting your existing targetted runtime, and recreating it.

Run configurations - I'd just got there!

The "No object DCH..." exception is a real so and so and seems to be being caused by activation not being able to see the mail bundle referenced by my bundle. bjansen's horrible hack is the only way I seem to be able to circumvent it. This despite Oleg's analysis that importing the mail bundle - rather that the individual pacakges - should resolve it.

Unfortunately, NDA's prevent me from attaching the app per-se, but I've PM'ed you with some details.

Cheers,
Skippy