Reputation: 5735
I would like to develop a web application in Java/Spring/Hibernate serving as a business platform that I could connect plugins to (i.e. CRM plugin, ware plugin, sales plugin). Those plugins could be dependent on other plugins in a tree manner. The parent project would be packaged as war having all the basic configuration and looks (Spring configs, CSS, scripts), ready-to-go user and group management, security settings, etc.
Altogether, I would like it to behave and look a bit like Joomla, but be built using different tools for different purposes. And I have a few questions concerning that project:
And last but not least, is this the right way to go, or is it a dead end? Would it be better to create a separate web app for those business needs?
Upvotes: 1
Views: 381
Reputation: 1906
*
And last but not least, is this the right way to go, or is it a dead end? Would it be better to create a separate web app for those business needs?
*
I have negative experiences in area modularisation with JPA. For example @Entity Customer is included in CRM module, but is intensively used from other. First natural idea one module = own persistence unit is very hard to realise, JPA should be across modules, and modularisation idea is gone to dead end, modules are not separated.
I use kind of modularisation "in process & in JAR", kind of structures is build, some menus / entities etc belong to "modules" in lighter sense
Upvotes: 0
Reputation: 4177
Do you know of any open source projects offering such a platform ready to go?
Have a look at Spring Roo
If not is maven applicable for managing those plugins?
Yes, it is. Check out how AppFuse uses it.
What is the best way to package and deploy those plugins? Again, check how Spring ROO or AppFuse does it.
Hope that helps.
Upvotes: 0
Reputation: 1708
There are lots of ways to build plugin modules. Some Ideas:
You could package every plugin module as a jar and in the classpath root of this jar, put a spring config file with the beans configuration, so if when you are using a specific plugin. You can "turn on" the beans of this package on a web application by simply adding this file to the contextConfigLocation parameter in your web.xml:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:module1.xml
classpath:module2.xml
classpath:module3.xml
classpath:module4.xml
</param-value>
</context-param>
So you are able to use those beans in your web application. Another way of doing this, would be to use a more annotations driven approach. Or you can mix the methods.
Some time ago, I structured a way to automatically hot-detect (in execution time, without having to restart the application) plugins in a desktop application by detecting all implementations of a specific abstract class (a contract) in the classpath. So, all that I had to do to build a new plugin, was to implement this "contract". I've used some "classloader" goodies to do this.
When talking about "modules" maybe you would like to see something about OSGi
Well... those are some ideas. I hope it helps in any way. ;-)
Upvotes: 1
Reputation: 4385
I think this is a fine way to design a web application, depending on the requirements. I use plugins because I had several clients using the same codebase with different requirements. If you are developing for one installation, I would say don't waste your time.
Now for the how-to. "Plugins" are a very vague concept. I've used plugins
The question is now, how does this work. The method interceptor works using a org.aopalliance.intercept.MethodInterceptor. The background processors use a TimerTask. The additional views in the web application use Spring MVC routing.
My plugins are packaged as JARs and discovered at application startup time as Spring application contexts.
This is all very general, but might give you some ideas to go off of.
Upvotes: 0