Introducing JForum3

[Migrated From Jforum.net]

Hello all,

this is the initial message to tell you all about the next major release of JForum, called "JForum3" for development purposes.

JForum currently is in a stage that does not support too much new features and integrations with legacy systems without hacking the code base. Problems like caching complexity, multi-database vendor and testability are real and make the developers day not so easy.

In the last past two years, JForum has grown and enhanced a lot, and feedback has been really great, with entusiastics from all parts of the world. The people who supports JForum - the developers, the guys who answer questions in the forum and etc... - really appreaciate that, and thank you very much.

In order to keep JForum growing and getting better, we decided to do a major refactoring in the core code, using the following technologies:

:arrow: Java 5: This one does not require an introduction. It is out there for some years now, being widely used and supported by almost all hosting companies and corporations. It provides more performance than Java 2, as well useful new language features.

:arrow: Web Framework: VRaptor (http://www.vraptor.org). It is a very nice and easy to use framework, going to help on the hardcore part of session management, action dispatching and request processing.

:arrow: Hibernate 3: will help a lot with multi database support.

:arrow: Template engine: probably Freemarker, which is already used in current versions of JForum. It is fast and easy. JSP 2 / JSTL are still considered, but we need good arguments on that.

Also, JForum3 is being sponsored and supported by a professional Java consulting company, Caelum. It is a brazilian company, and it's providing developers and help on the architecture.
Of course that the help of everyone is more than very welcome, and we all hope to bring you an excellent forum software.

We're going to update the Wiki with the TODO list, Roadmap and etc, and general discussions about development of JForum3 will use this forum.

More information about the development process and how to help can be found at http://www.jforum.net/doc/JForum3

Thank you all.

Rafael, in the name of the entire JForum Team.
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

I use JForum 2.1.7 because 2.1.6 lacks some bug fixes. I would like to go to JForum 3.0 ASAP if it is better than 2.1.7 with the *current* feature list.

JForum 3.0 is based on Java 5.0. I use 2.1.7 w/ Java SE 2.

What about Java SE 6 JVM, which is my next target version?


[originally posted on jforum.net by MyJForum]

[Migrated From Jforum.net]

MyJForum,

I would argue against using anything newer than version 5 of Java. Web app containers that are used in larger companies (ie. not Tomcat) that are leery of the cutting edge will not support SDK 6 for a while to come. Most don't support 5 yet. I know I can get 5 support, I have it now, however I can't just install SDK 6 on my servers because "our forum app now requires it". That would result in a support nightmare and the end of our usage of JForum.

While it may be feature-rich to be on the cutting edge you also get to find the bugs and performance issues and lack of development maturity.

my 2 cents.
E/.
[originally posted on jforum.net by ewise]

[Migrated From Jforum.net]

and on a development note:

would you be able to provide a guide on how to setup the development environment for JForum3? I know I would be more likely to help out / test / etc if I could *easily* setup a test/build environment in, say, Eclipse. I would argue that this is a very high priority issue to be resolved.

Sorry to be pestering on this front but I really am lazy these days and wrestling with project setup falls low on my priority list.

E/.
[originally posted on jforum.net by ewise]

[Migrated From Jforum.net]

You're absolutely right. We should make all the development aspects public available.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Cool!

I would like to ask you guys to create an easy interface to access some forum info, like to get username from a webpage outside jforum.

This will help a lot to integrate Jforum with other applications on the same website.
[originally posted on jforum.net by boaglio]

[Migrated From Jforum.net]

I have a few suggestions:

* Spring Framework for middle tier integration, Hibernate support and automatic transaction management. It is by far the best architected and most useful library I've ever used.

* I'd like to nominate Spring WebFlow as another excellent controller implementation. And maybe JSF for view rendering (at least for the admin site) to take advantage of its rich component model and ready availability of so many widgets. This would tie you down to JSP, however.

I have nothing against VRaptor -- which looks very interesting, btw -- but I wonder about the kind of developer adoption it enjoys. I've never heard of it and I am fairly active in open-source space.

* Maven to suceed Ant as the build and project management tool. (I can contribute Maven project descriptor immediately).

[originally posted on jforum.net by mrudman]

[Migrated From Jforum.net]

Maven for sure will not be used, neither WebFlow. Spring framework? We don't know.. probably no as well.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

> Spring framework? We don't know.. probably no as well.

I would seriously consider using Spring. Writing your own code to handle Hibernate session and transaction management is tedious, prone to error and redundant. Not to mention "dependency injection" functionality you get with Spring which is very useful in making key components pluggable.

I should also mention that we use JForum in commercial deployments and would like to help with the evolution of the product. I have plenty of experience with both Spring and Hibernate; I'd be more than happy to contribute expertise and/or development help.
[originally posted on jforum.net by mrudman]

[Migrated From Jforum.net]

I think one of the most important feature to add to JForum is the ability to run multiple independent Forum Communities using a single webapp. So the front page, search, user DB, etc would be unique to each community and multiple communities can be run on a single installation.

This is a common feature in many enterprise-strength products.
[originally posted on jforum.net by jvence]

[Migrated From Jforum.net]

jvence wrote:I think one of the most important feature to add to JForum is the ability to run multiple independent Forum Communities using a single webapp. So the front page, search, user DB, etc would be unique to each community and multiple communities can be run on a single installation.

You can do that by duping the forum into another name. You can get rid of the jar dups by dumping them into the tomcat lib space. Then all you are left with, basically is each forum config. files, which is what you want anyways. With a little work you run under JBoss or tomcat loadbalancer and multiple instances and have a enterprise class system.


[originally posted on jforum.net by MyJForum]

[Migrated From Jforum.net]

Please, let's focus on the architecture aspects for now, please. It is completely OK to ask for new features, but please add them to Jira and / or create a new thread, so we don't have cross posting here.

mrudman, I first thought that vraptor handled all hibernate stuff "by defautlt", but after talking to the guys who develop it, there was a kind of "OK" to use spring - in fact, they have integration to spring.

Of course there is plenty of ways to correctly handle hibernate transaction support in vraptor, but now I'm more open to the spring stuff.

How does / would it work?

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

I agree with the use of Spring for some political issues: it MAY help JForum to be more adopted and may help future integrations.

But for hibernate, spring is HEAVILY critized by the hibernate community on how its HibernateSupport works.

The following post is entitled "Using Abstraction frameworks to maintain control? Wrong bet.". Some comments are pretty sarcastic:
http://blog.hibernate.org/cgi-bin/blosxom.cgi/Emmanuel%20Bernard/abstractionframeworks.html

What is wrong in use a servlet filter to control your session and transaction lifecycle along the web request?


[originally posted on jforum.net by Paulo Silveira]

[Migrated From Jforum.net]

Paulo Silveira wrote:But for hibernate, spring is HEAVILY critized by the hibernate community on how its HibernateSupport works.

The following post is entitled "Using Abstraction frameworks to maintain control? Wrong bet.". Some comments are pretty sarcastic:
http://blog.hibernate.org/cgi-bin/blosxom.cgi/Emmanuel%20Bernard/abstractionframeworks.html

The main reason to use Spring on top of hibernate is not that it makes it easier to switch to anoher ORM-system later. The reason why I alway use spring in this context is that it really reduces the amount of code required to communicate with the database. Often I end up with a one-liner instead of 10-15 lines required when using Hibernate directly. The exception wrapper is actually a really benefit. It is way much easier to deal with the exceptions thrown across databases when using spring, instead of using Hibernate directly.

It might be true that some of the more advanced features in Hibernate can't be accessed via Spring. I don't know. But for JForum I'm sure that this will cause no problems. We have worked up against much more complex data structures without any problems.

Another thing is that the Spring framework provides other nice tools that could be used by JForum. And it is non-intrucive. We can use the parts that we like, and skip the rest.



[originally posted on jforum.net by lazee]

[Migrated From Jforum.net]

I think FreeMarker is a good choice. But if we integrates the template system via Spring, then it can be a choice made by the users.

JForum can ship with FreeMarker, but people can create their own templates in JSP, Velocity, and all the template languages supported by Spring.

This doesn't mean that we would have to use the full Spring Web Framework. VRaptor can still be used as planned.
[originally posted on jforum.net by lazee]

[Migrated From Jforum.net]

Rafael Steil wrote:Maven for sure will not be used, neither WebFlow. Spring framework? We don't know.. probably no as well.

Rafael

What do you have against Maven 2?

I really love it. And the site functionality would make it a lot easier to generate project documentation on the fly.
[originally posted on jforum.net by lazee]

[Migrated From Jforum.net]

As you said the codebase of JForum has grown a lot. I think it might be a good idea to separate the codebase into some sub-projects. This makes it a lot easier to have a large group of developers on the projects, and also to have different people responsible for the different parts of the codebase. It also simplifies the unit-testing process.

This is just a structural issue in CVS.

For example we could have something like:

jforum-core
jforum-web
jforum-tools

Maybe own subprojects for the unit-testing of the different databases.

Again Maven is a great tool to help us out on these issues!

[originally posted on jforum.net by lazee]

[Migrated From Jforum.net]

Rafael Steil wrote:
Of course there is plenty of ways to correctly handle hibernate transaction support in vraptor, but now I'm more open to the spring stuff.

How does / would it work?

Rafael

We can make a demo implementation on how this would look if you're interested.
[originally posted on jforum.net by lazee]

[Migrated From Jforum.net]

lazee wrote:
What do you have against Maven 2?

I really love it. And the site functionality would make it a lot easier to generate project documentation on the fly.

All documentation is being written on the Wiki. I really think that we can be really fine without maven.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

lazee wrote:
We can make a demo implementation on how this would look if you're interested.

That would be great.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

> How does / would it work?

Spring provides some base classes which JForum DAO classes would extend. Spring support code handles proper usage, flushing and closing of Hibernate sessions and works with Spring-configured Transaction manager. The transactions are demarcated declaratively in Spring config XML. Under the hood, Spring uses Aspected-Oriented Programming (OP) libraries which intercept method calls on business obejcts and seamlessly execute transaction handling code.

> What is wrong in use a servlet filter to control your session and transaction lifecycle along the web request?

1) Transaction boundry demarcation; you have no control. The entire request executes in a single transaction and more importantly holds resources (like DB connection) for the entire time request is executing (including view rendering and other logic that has nothing to do with DB access).
2) You tie your transaction management code to web tier. May not be a big issue with webapp like JForum. BTW, Spring provides an implementation of this pattern as well.

[originally posted on jforum.net by mrudman]

[Migrated From Jforum.net]

Well, transaction scope is not an issue, as we either have to commit everything or rollback all.

The second point (about servlet filter) seems better.

It's OK to use a generic dao with Spring?

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Rafael Steil wrote:It's OK to use a generic dao with Spring?

It depends on what you mean by OK It can be done easily. But one of the great things about Spring in database context is the abstraction layer for exceptions, and the jdbc-templating system.

So I think Spring should be the choise wether you stick to a generic approach for a while, or you implement Hibernate at the same time.

It would probably be the best approach to introduce Spring first, and then Hibernate when that is done. Then you will see the great benefits of Spring.

Another thing is that Spring can be introduced step-by-step. It's non-intrucive.

I'll be more than happy helping out designing how to use Spring/Hibernate in JForum 3.


[originally posted on jforum.net by lazee]

[Migrated From Jforum.net]

mrudman wrote:> How does / would it work?

Spring provides some base classes which JForum DAO classes would extend. Spring support code handles proper usage, flushing and closing of Hibernate sessions and works with Spring-configured Transaction manager. The transactions are demarcated declaratively in Spring config XML. Under the hood, Spring uses Aspected-Oriented Programming (OP) libraries which intercept method calls on business obejcts and seamlessly execute transaction handling code.

This is a part of the truth. The point is that you _can_ extend your DAO with the Spring classes. And you _can_ use the AOP parh of Spring if you like, you do not have to. This is what Spring is all about -- choices. You are not forced into a framework with four walls around you. You make your own choices on what parts of the project you will like to use.


[originally posted on jforum.net by lazee]

[Migrated From Jforum.net]

Well, transaction scope is not an issue, as we either have to commit everything or rollback all.

You are probably right but there may be some cases where this not true. For example, you might want to record a page view even though there's been an error of some sort. Perhaps this example is a bit contrived but the point is that transaction boundries ought to be at business logic level and not at HTTP request level.

I highly recommend skimming through the Spring documentation to get a sense for the features it offers:

http://static.springframework.org/spring/docs/2.0.x/reference/index.html
[originally posted on jforum.net by mrudman]

[Migrated From Jforum.net]

I kinda know what Spring has to offer, but from theory to practice is a long way, so that's why I count on with you guys

About the generic dao question, I asked that because the HibernateGenericDAO we're using on JForum 3 prevents us of doing all the CRUD code in 95% of the time, which is great.

As I said before, I'm OK to go with Spring, as long as someone post here the plan to use it / how to use it on JForum 3.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

I'm learning Spring and Hibernate for a while. I think this article might be helpful for beginners.
http://www.developer.com/java/ent/article.php/3577101
If we want to use Hibernate Annotations and Spring MVC on JForum 3, then we can avoid some XML config files on Hibernate.

[originally posted on jforum.net by andowson]

[Migrated From Jforum.net]

Hibernation Annotations are being used already. Spring MVC will not be used, as we have VRaptor for that.

Thanks for the article. I'll read it.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Hi,

Just a quick note to second the use of Spring. At Alfresco we use Spring as the backbone of our product and it has proved to be very useful indeed. I wont bore you with the details, but its definatly worth some time investigating whether you could use it.

We also use Java 5, Hibernate, Lucene and various other Java O/S products, its a very effective stack to work on.

I'd love to see JForum running on Alfresco one day, but I'm sure you've got enough on your plate at the moment ;)

Keep up the good work,

Roy
[originally posted on jforum.net by rwetherall]

[Migrated From Jforum.net]

OK, Guys. Just to avoid some confusion, alright?

Some decisions I think we should summarise.

1st. We're gonna use the following tecnologies:
- Hibernate 3 - thru Spring;
- VRaptor - MVC;
- Freemaker - thru Spring;

2nd. We're not going to use: MAVEN.
Obs.: Maven 2 can also help with JUnit regression tests... According to this: http://maven.apache.org/what-is-maven.html

3rd. I vote for JForum3 subprojects as proposed by lazee.


As soon as these points are settled down, I shall update Wiki, alright?


D�rico Filho
[originally posted on jforum.net by dericofilho]

[Migrated From Jforum.net]

dericofilho wrote:1st. We're gonna use the following tecnologies:
- Hibernate 3 - thru Spring;
- VRaptor - MVC;
- Freemaker - thru Spring;

I'm looking forward to this. I guess that we will configurate Spring via XML?

dericofilho wrote:
2nd. We're not going to use: MAVEN.
Obs.: Maven 2 can also help with JUnit regression tests... According to this: http://maven.apache.org/what-is-maven.html

I have no problems with that someone doesn't fancy M2, even though I love it. But I will suggest that we create a structure similar to the one Maven uses. And I also sugges that we create a new root structure in cvs for JForum. This way we can have checked in other files without interferring with the project itself. This could look something like:

jforum--+
        +project+
                + jforum-core+
                |            + src---+
                |                    +main+
                |                    |        +java
                |                    |        +webapp
                |                    |        +resources
                |                    +test+
                |                         +java
                +jforum-taglib
               ...                               

This way it would be really easy to use Maven for building the reports without using it for the actual building.

dericofilho wrote:
3rd. I vote for JForum3 subprojects as proposed by lazee.

Great, I think this will make it much easier to have different maintainers for each sub-project. And it will also make it more likely that other projects will adopt parts of what we are doing, and vice versa.
[originally posted on jforum.net by lazee]

[Migrated From Jforum.net]

Two things:

1) We probably will go with Tabligs instead of Freemarker
2) Exactly where Spring will be used? The only major point one was shown is transaction scope, but that can be easily handled by VRaptor. Ok, there is the Hibernate thing. How Spring enhances it?

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Rafael Steil wrote:Two things:

1) We probably will go with Tabligs instead of Freemarker
2) Exactly where Spring will be used? The only major point one was shown is transaction scope, but that can be easily handled by VRaptor. Ok, there is the Hibernate thing. How Spring enhances it?

Rafael

How do you think we should use the taglibs? Since we already have a controller I don't see the great benefits of that. The data/objects can be loaded into objects that are presented to the jsp-layer. The jstl-logic should manage the logic in the presentation layer. Something like we do it in freemarker already.

I think we should concentrate on the hibernate/spring part of v3, and keep freemarker a while longer. Then descide on JSP/Freemarker when that is done.


[originally posted on jforum.net by lazee]

[Migrated From Jforum.net]

No, I don't mean JSTL. I mean the suggestions made at https://coderanch.com/t/576678

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Rafael Steil wrote:No, I don't mean JSTL. I mean the suggestions made at https://coderanch.com/t/576678

Rafael

Well, that will work. But I don't buy all the arguments. Designers will still need to know about available field names, what tags that are available (And that will be a lot), what tags that can be used in each context, and so on.

The important thing is that we do this in a way where people easily can switch to another template approach.
[originally posted on jforum.net by lazee]

[Migrated From Jforum.net]

I find the sintax cleaner, but that almost only a cosmetic thing, so I will not focus on that.

The major point I see for taglibs is, that using them, we can enchance the way users can extend JForum. Using freemarker, we have to write the Java code and the ftl macros - which many times get kind of complex and hard to read due to the sintax and features available.

With taglibs, on the other hand, we can have a banner plugin (yeah, I really mean plugins for JForum 3) like

<jforum:banner with='500' height='200'/>

Then, the Java code would be concentrated on business objects, with full access to the JForum API, without any nasty tricks.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

Rafael Steil wrote:Maven for sure will not be used, neither WebFlow. Spring framework? We don't know.. probably no as well.

Rafael

Hi Rafael,

I'm nor a JForum developer or user (hopefylly the latter soon), but I have to ask why you don't want to use Maven and, especially, why you are so certain ("for sure") about not using it.

Recently migrated a big Ant project (two separate applications + a web application) to Maven at work and I don't regret it all.

Bear in mind that if you use Maven it will be A LOT easier for people to help out with patches etc because of a shorter startup time (people kno how to build, the Maven structure is well-known etc).

Also, I've been reading about to choices of different libraries, frameworks etc to use and I have a simple question: why not use things that people are familiar with? I assume that you want to the community to ship in as much as possible and I believe that people are more familiar with, e.g., Spring than VRaptor.

Keep up the good work!

Kind regards,
Jimisola
[originally posted on jforum.net by jimisola]

[Migrated From Jforum.net]

I usually don't like to add frameworks and tools that are there only because one tiny part is used. I didn't like Maven 1, as it was very complex and inefficient.

I heard some good things about maven 2, but the only thing it was said about the help Maven could bring to JForum is to deply builds - and, afaik, ant handles that.

Could you suggest some good areas where maven can help improving JForum?

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

hi, I'm new and have just begun to evaluate it for 30 mins. :-) This discussion sounds very interesting.

For Spring, I think it is not good to *just* view it as a simplier way to use Hibernate or whatever. It is an IoC framework by nature, i.e. provides dependency injection which means it constructs instance and injects to your objects. This reduces a lot coupling/dependency, make code much simplier, beans are more configurable, classes more testable. (I speak from my exp of design and implementing a equities trading system for an i bank with Spring 2)

I think using an IoC framework is a must for any new application development project. And Spring is a good choice as it should be the most popular and mature one. Other IoC should do well, but they don't provide those nice features such as those "easy-to-use" JDBC or Hibernate features.


[originally posted on jforum.net by mingfai]

[Migrated From Jforum.net]

Hi to all!

We are new in this forum.
During our studying and by doing some little projects, we have used Hibernate with Spring for the communication with the DB. And also we used JSF and Facelets for the view.
We can recommend both technologies. In our opinion it's a great idea.

We've read, that you want to use Hibernate with Spring and there was a question about the use of GenericDAOs and the configuration (XML) of Spring for this.
Here's an interesting link we've used for building our application: GenericDAO and applicationContext.xml with IoC and AOP

If you are interested, we can show some source from it.

Greetings,
Melanie & Stefan
[originally posted on jforum.net by melanie_stefan]