Openfire's source code: Restructuring + Java EE 7 support?

Openfire Openfire Dev
1

Hi,

I’ve recently had a closer insight into Openfire’s source code since I felt like contributing something (which I also did: OF-638).

However there were some inconveniences and things that made me think “WTF!?”…

The first hurdle was to get Openfire running from source. I needed to manually add a whole bunch of libraries to the classpath and

afterwards I also had to manually add the folders “i18n”, “java” and “resources/jar” to the classpath.

I also had to build the project with ANT first and then set the openfireHome variable. This is of course all explained in DOC-1020, but I think it could be easier.

I am used to Maven-structured projects, where you can just import a pom.xml file and everything else is done for you automatically by the IDE.

So my first question is, if you have ever thought about cleaning up the directory structure, i.e. using a standardized (?) structure like:

src/main/java

src/main/resources

src/test/java

src/test/resources

There are also some folders, which are probably no longer needed (like “resources/images-dev” or “javadoc”) and the package structure in general is too flat/unorganized for my taste.

And have you ever thought about moving to a (in my opinion) more modern build tool like Maven or Gradle?

Second question: Java EE support

Have you ever thought about using Java EE technologies or well established Java standards in general?

Especially I am thinking about:

  • Context Dependency Injection (CDI) (javax.inject)

  • Java XML Binding (JAXB) for XMPP processing. (javax.xml.bind).

  • Java Persistence API (JPA) for storing data (javax.persistence)

  • maybe even REST WebServices, e.g. for registering users.

I think by using standard technologies like that, which

a) are easier to use and maintain,

b) have wide-spread knowledge among Java developers,

c) are supported by various Java EE application servers

the Openfire project would benefit from more contributors and could be more easily used in Java EE environments (i.e. in a JBoss server).

The problem I am having with the current code base is, that most of it seems to be nearly 10 years old (according to the copyright header) or uses old technologies.

I’ve thought about contributing some more stuff, but it’s less fun working with outdated technologies.

I know, these are probably only dreams, which won’t get real in the short-term future because Openfire lacks developers.

But I’d like to hear your opinions or your vision about Openfire’s future, technology-wise.

Oh, and btw: I was suprised, that there are hardly any unit tests (only 2 for openfire package and only some more for the util package). What’s up with that?

2

I expect that you have already a local git repo with .gitignore for javadoc etc.

Porting the code and the database schema to 2015 will be a big task. Moving the code folders around and then releasing it on github will break the version history but with only a few devs. that may be acceptable.

Getting rid of the Jetty web server and building war files may be another task.

Building rest webservices as plugins is already possible.

Using an API like JPA is one thing most developers can do - anyhow only little understand the API and use it right. Looking at performance it is often better not to use API layers - I spent some time looking for poor performance: Often APIs with wrong (standard) parameters are involved. So for the core Xmpp processing I’d stay away from APIs.

3

No, I checked out Openfire’s source with SVN, as described in DOC-1020 and http://www.igniterealtime.org/downloads/source.jsp

How is the SVN trunk related to github repositories? Can you do pull requests from a local github clone to the SVN? Or where is the HEAD/trunk revision? Or how is it managed?

@JPA: I can’t say anything about, whether it has performance issues, but IMO it is not that hard to work with.

@JAXB: I’ve googled for performance JAXB vs StAX vs DOM.

https://weblogs.java.net/blog/spericas/archive/2005/12/dom_vs_jaxb_per_1.html

Serializing is faster for JAXB, but deserializing is faster for DOM. But this benchmark is from 2005!

http://tedone.typepad.com/blog/2011/06/unmarshalling-benchmark-in-java-jaxb-vs-s tax-vs-woodstox.html

=> JAXB is fastest.

So, I’d not be too worried about JAXB performance, and neither by JPA as it’s used in many enterprise solutions.

4

CSH wrote:

No, I checked out Openfire’s source with SVN, as described in DOC-1020 and http://www.igniterealtime.org/downloads/source.jsp

How is the SVN trunk related to github repositories? Can you do pull requests from a local github clone to the SVN? Or where is the HEAD/trunk revision? Or how is it managed?

I dont think it is at this point. I believe Openfire is still using SVN as its official source.

On the storage front, I think Openfire needs a proper DAO layer so that alternative storage technologies can be used if one desires such a solution. For instance, I am pretty sure I have seen posts before from someone trying to use MongoDB. A proper separation with a well defined model would make it easy to do a couple of things.

  • Allow developers to easily adapt different technology solutions when it makes sense for their own usage. (NoSQL, OODB, JPA, Hibernate…)
  • Easily allow modifications to make usage of DB specific features.
  • Have parts of the persistence layer replaced. For instance, using a different DB for one module only.

This doesnt mean that we shouldnt use JPA for the default implementation of such a layer, but only that we abstract the usage of persistence so that alternatives are easily possible.

5

CSH wrote:

I am used to Maven-structured projects, where you can just import a pom.xml file and everything else is done for you automatically by the IDE.

And have you ever thought about moving to a (in my opinion) more modern build tool like Maven or Gradle?

Have you ever thought about using Java EE technologies or well established Java standards in general?

Oh, and btw: I was suprised, that there are hardly any unit tests (only 2 for openfire package and only some more for the util package). What’s up with that?

My comments on this. Guus had expressed interest in going to Maven: OF-546 and it was one the dreaming list for Openfire 4.0 release.

You use the term “you”, but there is no master mind or dictactor calling the shots with openfire. We are a bunch of volunteers where bringing code speaks loudly

In general, openfire/Jive messenger is a very old Java project. Things are done somewhat differently these days and there is a lot of legacy code in the tree.

Thanks for your interest in writing code for Openfire, we desperately need more help. I can help you get whatever permissions you need into our dev system, so to keep you going! We sort of ask that Guus be happy with large code changes that go in.

daryl

6

Openfire needs a proper DAO layer…

Yes, that’s my thinking, too. Although I don’t believe someone would write their own persistence layer implementation (e.g. for their very specific DB). JPA, or rather an implementation thereof (e.g. Hibernate) comes with many SQL dialects. It’s probably easier to just switch to another DB dialect then.

Anyway, a proper DAO layer would be a good place to start.

Thanks for your answer!

7

It looks like there was already some work done on this front, as there is a maven branch already created, but hasn’t seen any commits in over a year.

You (CSH) could contact Guus to see what the status is if you want to try to move it forward.

8

http://community.igniterealtime.org/polls/1058

While few would probably want to rewrite the entire persistence layer, I could definitely see someone wanting to implement something specific for something like pubsub, for instance. Where a use case might get into extremely high volumes.

In any case, this approach would make it easy to do so. Openfire just has to provide the default implementation, which can actually be the current one, hidden behind a DAO layer, if one wants to minimize the amount of code that has to be rewritten. Once abstracted, the implementation can just be refactored over time.

9

LG wrote:

Moving the code folders around and then releasing it on github will break the version history but with only a few devs. that may be acceptable

No, it wont break the version history. Not sure what makes you think so.