powered by Jive Software

Hard-coded module names (Dependency Injection)

Hi there, I’m working on a charity project - it’s a social platform. Now I’m designing the Instant Messaging system.

I’ve decided to use OpenFire. After few hours of exploring the code. Thanks a lot for that ! Great job !

As we need a lot of cusomization (almost all these things could be solved by plugin), I have found one ugly thing.

I need custom roster - users are not allowed to change their roster, roster is loaded from db, but this has a different schema than ofRoster table. As it’s possible to change authentification of user management (custom db integration guide), I need the same stuff with rosters !

Unfortunately, I’m afraid, that with current design it’s not possible without hacking the core. I really don’t want to hack the nice OpenFire core.

All this stuff is done by RosterManager and RosterItemProvider respectively. The design of OpenFire is really well done. Everything is abstracted, but then, at the end, all module names are hard-coded in XMPPServer::loadModules(). Why ?

I hope, it could be done like that: (something like Dependency Injection)

// XMPPServer method loadModules()
private void loadModules() {
  // Load boot modules
  loadModule(JiveGlobals.getProperty("xmpp.module.rosterManager", RosterManager.class.getName()));
  // ... other modules the same
}

With this design, it would really easy to extend any core module, without hacking the core - the new class would be in some plugin package.

What do you think about this idea ?

If I’m missing something, please let me know. Maybe there is a different way, how to implement something like custom rosters…

At the end, thanks again for OpenFire, you all did great job. It’s really well done !

Hi,

modifying the code this way would be quite easy. Anyhow it does not seem to be save, especially if the RosterManager is changed your class may fail (unless you add this modification). So creating interfaces may be the much better choice.

LG

Yes, it’s really easy to modify the code… I’ve already done it.

But I hate hacking the core

This post was something like an idea how to improve OF.

Especially for rosters - there are interfaces for GroupProvider, UserProvider, AuthProvider, …

So, I guess it would be helpfull to create another interface for RosterItemProvider…

And then, in RosterItemProvider.getInstance() use some configuration…

Used class must implement RosterItemProvider interface of course.

Then, it would be possible to create your own roster system without hacking the core…

Anyway, thanks a lot for the reply.

Hi,

feel free to hack the core and to provide a patch. There are only a few developers so providing patches is usually a good and quite fast way to get optimizations or modifications into Openfire.

LG

I’ve actually always wondered why these “modules” are so conceptually different from plugins. Some of them could be considered ‘optional’ - we should allow users to disable those.

In short, I’d welcome constructive patches that not only hack around these problems, but solve them in a constructive way.

Ok, that’s not problem. I know OpenFire for few days, but I really like it. It has helped me a lot, so I could help as well…

At first I think, it’s good idea to write patch for RosterItemProvider:

  • add interface RosterItemProvider (same as UserProvider, GroupProvider, etc.)

  • change current RosterItemProvider to DefaultItemProvider

  • add possibility to define custom class

  • add JDBCRosterItemProvider as well

So I will do this as a patch, if you have any comments for that, feel free to share them…

I absolutely agree, that whole app should be modular, I mean there is no reason (for me) to have modules and plugins…

At this time, the plugins are not so powerfull, as you can not use their libraries for bootstrap, they are initialized very late…

It should be better to use only plugins (or modules, its not important how we call them) and everyone can enable/disable specific module… Add his own, etc…

But this is a change of whole conception.

Thanks for these replies.