Can't make Jodd Mail work in OSGi environment

[djsuprin]

Hello,

I'm trying to integrate Jodd Mail in my OSGi-enabled application but when I run ReceiveMailSession session = imapServer.createSession(); it throws java.lang.NoClassDefFoundError: jodd/Jodd. I believe that it happens because both jodd-core and jodd-mail packages export the same package jodd. I'm not an OSGi expert but it seems that one package is overridden by the other one. It leads to missing classes making Jodd impossible to be used in an OSGi environment.

I took OSGi-fied maven dependencies from mvnrepository.com.

Maybe if I missed something and it is possible to use Jodd in OSGi please let me know. But if it is an architectural issue can you please tell if you're planning to do something about it in the nearest future?

Kind regards, Vladimir

[igr]

Hello Vladimir, thank you bringing this issue up!

You are right, it seems there is a problem with exporting the root package jodd. When I remove this package from use, things start to work better, but I need to check this more.

One question for you: do you think it make sense to have Jodd jar as bundles? I mean, users always can change the bundle class path and include Jodd's jars; do you think that having Jodd jars a bundles brings a value?

[igr]

I've made some changes and now it looks like Jodd jars are correctly loaded in OSGI. I made two important (internal) changes:

• Jodd Core module now has optional import on some java classes
• All Jodds modules have been moved to packages, so the jodd package exists only in the jodd-core module (i.e. jar).

Please note that it would be a good practice to initialize Jodd modules manually in some your Activator, like this:

JoddCore.init();
JoddBean.init();
JoddMail.init();
...

since in OSGI environment we can not use classloading to find modules automatically. However, for email this is not required, only for those Jodd modules that have optional dependencies between them.

Hope this make sense :)

If you have time, please try to build the latest code base. You might need to change first the version in your gradle build, as OSGI complains on current version. Let me know how it worked for you!

[djsuprin]

Hi Igor,

that's what I did yesterday, added jars in a bundle's classpath. It works very well. Thanks by the way for this great software! However I can imagine a couple of use cases when having Jodd components as bundles is convenient:

• they can be easily upgraded without stopping the environment. It's great for production systems;
• in my case there is only one service that needs Jodd Email so it's not a problem to embed it inside my bundle. But in case there are many components that depend on your different Jodd components it's simpler to keep and maintain it in a single place also keeping other services lighter. In the end it is a philosophy of OSGi to make software as modular as possible. :)

Kind regards, Vladimir

[djsuprin]

Thanks for fixing that! I will surely test it and let you know.

[igr]

Yes, you are absolutely right, thats why I go ahead and made the changes ;) We are just close to releasing the next version, so in one moment I thought I wound not be able to make it soon enough :)

Thank you!

[igr]

One question: since Jodd has internal modules (it needs to track optional dependencies), you would need to init the modules. Would it make sense to add simple OSGI Activator for each module that will do the initialization automatically?

[djsuprin]

I can't tell as I haven't tried other Jodd components except Jodd Mail. This one as you mentioned is more like a set of utility classes, not services so maybe it doesn't need an Activator. Initializing the modules in an activator is a good idea. However OSGi assumes the special approach and way of software design so I guess it doesn't worth to use it for anything more complex than that.

[igr]

Thank you! I would use Activator just for initializing Jodd modules, so they can be aware of each other. Half of the Jodd tools are frameworks, and there is some optional dependencies involved, hence the initialization. Thank you!